Re: [openstack-dev] [astara] Retirement of astara repos?

2018-08-20 Thread Mark McClain
Yeah. I’ll post the retirement commits this week.


> On Aug 18, 2018, at 13:39, Andreas Jaeger  wrote:
> Mark, shall I start the retirement of astara now? I would appreciate a "go 
> ahead" - unless you want to do it yourself...
> Andreas
>> On 2018-02-23 14:34, Andreas Jaeger wrote:
>>> On 2018-01-11 22:55, Mark McClain wrote:
>>> Sean, Andreas-
>>> Sorry I missed Andres’ message earlier in December about retiring astara. 
>>> Everyone is correct that development stopped a good while ago.  We 
>>> attempted in Barcelona to find others in the community to take over the 
>>> day-to-day management of the project. Unfortunately, nothing sustained 
>>> resulted from that session.
>>> I’ve intentionally delayed archiving the repos because of background 
>>> conversations around restarting active development for some pieces bubble 
>>> up from time-to-time.  I’ll contact those I know were interested and try 
>>> for a resolution to propose before the PTG.
>> Mark, any update here?
> -- 
> Andreas Jaeger aj@{,} Twitter: jaegerandi
>  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>   HRB 21284 (AG Nürnberg)
>GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Retirement of astara repos?

2018-01-11 Thread Mark McClain
Sean, Andreas-

Sorry I missed Andres’ message earlier in December about retiring astara. 
Everyone is correct that development stopped a good while ago.  We attempted in 
Barcelona to find others in the community to take over the day-to-day 
management of the project. Unfortunately, nothing sustained resulted from that 

I’ve intentionally delayed archiving the repos because of background 
conversations around restarting active development for some pieces bubble up 
from time-to-time.  I’ll contact those I know were interested and try for a 
resolution to propose before the PTG.


> On Jan 10, 2018, at 5:20 PM, Sean McGinnis  wrote:
> While going through various repos looking at things to be cleaned up, I 
> noticed the last commit for openstack/astara
> was well over a year ago. Based on this and the little bit I have followed 
> with this project, it’s my understanding that
> there is no further work planned with Astara.
> Should these repos be retired at this point? Or is there a reason to keep 
> things around?
> Thanks,
> Sean McGinnis (smcginnis)

OpenStack Development Mailing List (not for usage questions)

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

2017-03-10 Thread Mark McClain
Development of the project has been quiet for some time as the developers have 
moved onto to other work.  The main project repo is astara [1] and which had a 
few commits last fall. At summit in Barcelona, we solicited for those 
interested in continuing Astara.  For those interested in continuing Astara, 
I’m happy to help transition resources.



> On Mar 10, 2017, at 10:32 AM, Dariusz Śmigiel  
> wrote:
> Hey,
> astara-neutron repo seems to be broken for a long time [1].
> Last merged patches are dated on July 2016 [2]. After that, there is a
> queue with jenkins -1s. It doesn't look like to be maintained anymore.
> Is there an interest in the Community to fix that?
> BR,
> dasm
> [1]
> [2]
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

[openstack-dev] [election][tc] Not Running for Re-Election

2016-03-31 Thread Mark McClain

I wanted to drop a note to let everyone know that I will not seek re-election 
to the TC for this cycle.  I’ve really enjoyed working with everyone in our 
community through the TC the past three years. I’m super excited by the 
candidates who are running where they’ll lead our community.  I’ll still be 
around on working on various networking initiatives and look forward to seeing 
many of you in Austin.


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] Austin Design Summit track layout

2016-03-29 Thread Mark McClain

> On Mar 28, 2016, at 6:28 AM, Thierry Carrez  wrote:
> Hi everyone,
> Please find attached in PDF the proposed layout for the various tracks at the 
> Design Summit in Austin. I tried to take into account all the talk conflicts 
> and the constraints that you communicated, although as always there is no 
> perfect solution.
> Let me know if you see major issues with it. It's difficult to make changes 
> at this stage as they quickly cascade into breaking all sorts of constraints, 
> but we may still be able to accommodate some.
> Eagle eyes readers will see that there are a number of fishbowl slots in 
> green (on Thursday early morning and end of afternoon). If your team is 
> interested in them (and that does not trigger a conflict), let me know and 
> we'll try to give them out.
> Once the layout is official, I'll proceed to publish it on the official event 
> schedule. Then as each project team comes up with session titles and content, 
> we'll gradually push those to the official schedule. The goal is to have all 
> the content finalized for mid-April.
> Thanks all!
> -- 
> Thierry Carrez (txt)

Would it be possible to move the Astara fish bowl session to Thursday morning?  
It would avoid the conflict with Tacker.  We’re hoping to see where the teams 
could cooperate across projects in the future.

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [stable] meeting time proposal

2015-12-16 Thread Mark McClain

> On Dec 16, 2015, at 2:12 PM, Matt Riedemann  
> wrote:
> I'm not entirely sure what the geo distribution is for everyone that works on 
> stable, but I know we have people in Europe and some people in Australia.  So 
> I was thinking alternating weekly meetings:
> Mondays at 2100 UTC
> Tuesdays at 1500 UTC

Were you thinking of putting these on the opposite weeks as Neutron’s 
Monday/Tuesday schedule?

> Does that at least sort of work for people that would be interested in 
> attending a meeting about stable? I wouldn't expect a full hour discussion, 
> my main interests are highlighting status, discussing any issues that come up 
> in the ML or throughout the week, and whatever else people want to go over 
> (work items, questions, process discussion, etc).

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron] virtual machine can not get DHCP lease due packet has no checksum

2015-06-01 Thread Mark McClain

 On Jun 1, 2015, at 7:26 PM, Tidwell, Ryan wrote:
 I see a fix for merged during 
 Kilo.  I'm wondering if we think we have identified a root cause and have 
 merged an appropriate long-term fix, or if was merged just so there's at least a fix 
 available while we investigate other alternatives.  Does anyone have an 
 update to provide?

The fix works in environments we’ve tested in.  Are you still seeing problems?

OpenStack Development Mailing List (not for usage questions)

[openstack-dev] TC candidacy

2015-04-22 Thread Mark McClain

I'd like to announce my candidacy to continue serving on the Technical 

OpenStack is a growing community comprised of many parts and we we must view 
ourselves as one unit. As a TC member, I will continue to place the interests 
of the larger community over those of those of individual projects.

There are several key areas I'd like to see the TC focus:

  The Technical Committee should serve as a high level forum to facilitate 
defining cross project technical and procedural requirements. While many of our 
programs share commonalities, there are still too many differences in policies 
and technical decisions. The addition of cross project specifications is a step 
towards unifying the development process and design standards within our 
community.  As we accept more projects under the new governance model, the TC 
should work to facilitate developer mobility across projects by promoting best 
practices.  Increased mobility will strengthen our community as it helps to 
prevent silos. Reviews are an another area the TC should focus on during the 
upcoming cycle. The TC should review and work with projects to improve the 
contributor and reviewer experience when contributing to projects both big and 

Cross Project Communication
  Our codebase has grown significantly over the years and a contributor must 
invest significant time to understand and follow every project; however many 
contributors have limited time must choose a subset of projects to direct their 
focus.  As a result, it becomes important to employ cross project communication 
to explain major technical decisions, share solutions to project challenges 
that might be widely applicable, and leverage our collective experience.  The 
TC should seek new ways to facilitate cross project communication that will 
enable the community to craft improvements to the interfaces between projects 
as there will be greater familiarity between across the boundary.

Unified Experience
  For OpenStack to be successful we must strive to provide a unified experience 
for both users and deployers. During the previous cycles we have made progress 
in this area, but there is still work to be completed. When visiting user 
groups, a common thread during discussion is the installation experience. The 
TC should identify common installation configurations and work with projects to 
optimize installation and upgrades.  Equally important is the users. The TC 
should work to promote and support projects such the OpenStack client and SDK 
which aim to provide users with tools that are well maintained, documented and 
easy to use. Our community has invested significant effort to improve this 
experience and this should remain a focus going forward.

About Me
I have served on the Technical Committee for last two years and I am a former 
PTL. Believing that OpenStack is a unified community, I have contributed code 
and reviews to many of our projects since Sent from my iPad

We have built a very special open community through the contributions of many.  
These contributions have powered our phenomenal growth and I'm excited about 
our future!


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] Cinder Third-Party CI: what next? (was Re: [cinder] Request exemption for removal of NetApp FC drivers (no voting CI))

2015-03-24 Thread Mark McClain

 On Mar 24, 2015, at 9:30 AM, John Griffith wrote:
 On Tue, Mar 24, 2015 at 4:52 AM, Thierry Carrez wrote:
 Walter A. Boring IV wrote:
  Thanks Mike for all of your efforts on this,
 I think Mike checked all the possible boxes to give fair warning to
 driver owners.
 It's hard to say no in the name of quality. It's so much easier to
 just say yes and avoid all the hatemail and the pressure.
 Mike did the right thing, he did it the right way, and he needs all the
 support the rest of our community can give him.
 Thierry Carrez (ttx)
 OpenStack Development Mailing List (not for usage questions)
 ​Just adding my support to the very hard thing that Mike is doing here.  As 
 mentioned discussions and warnings have gone on ad nauseum over the last 
 year.  I may not agree with some of the wording or depictions, ​and I 
 certainly am empathetic here; but the fact is this has been a year long 
 process that was communicated, discussed and help provided.  NOTE this 
 started at the summit in Atlanta!!!
 CI can be hard, the work of a lot of people in Cinder, the Infra team and 
 others have made it a lot easier.  People have also spent countless hours 
 writing code for this, setting up their own systems and helping others out 
 via IRC and even a dedicated weekly meeting as well as a time slot every week 
 in Cinders meeting.  
 If the reasons were different than my data center went offline or I can't 
 host a public web server I might have a different opinion.  But I have a 
 really hard time with this sort of thing coming from companies the size and 
 scale of Microsoft, NetApp and Oracle.
 Anyway, I do feel bad but not as bad as I'd feel for everybody that worked 
 their butts off on this whole topic for the last year if we turn around and 
 punt it again.

Echoing both Thierry and John.  I support Mike’s decision to enforce the 
requirement. Maintaining drivers in the tree comes with responsibilities to the 
community and 3rd party CI is one of the them.  Mike enforcing this requirement 
was the right action even if a hard one to take.

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron] Multiple template libraries being used in tree

2015-02-02 Thread Mark McClain
You’re right that the Mako dependency is really a side effect from Alembic.  We 
used jinja for tempting radvd because it is used by the projects within the 
OpenStack ecosystem and also used in VPNaaS.


 On Feb 2, 2015, at 3:13 PM, Sean M. Collins wrote:
 Sorry, I should have done a bit more grepping before I sent the e-mail,
 since it appears that Mako is being used by alembic.
 So, should we switch the radvd templating over to Mako instead?
 Sean M. Collins
 OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [neutron] Changes to the core team

2015-01-23 Thread Mark McClain

 On Jan 22, 2015, at 12:21 PM, Kyle Mestery wrote:
 On Thu, Jan 15, 2015 at 4:31 PM, Kyle Mestery wrote:
 The last time we looked at core reviewer stats was in December [1]. In 
 looking at the current stats, I'm going to propose some changes to the core 
 team. Reviews are the most important part of being a core reviewer, so we 
 need to ensure cores are doing reviews. The stats for the 90 day period [2] 
 indicate some changes are needed for core reviewers who are no longer 
 reviewing on pace with the other core reviewers.
 First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been 
 a core reviewer for a long time, and his past contributions are very much 
 thanked by the entire OpenStack Neutron team. If Sumit jumps back in with 
 thoughtful reviews in the future, we can look at getting him back as a 
 Neutron core reviewer. But for now, his stats indicate he's not reviewing at 
 a level consistent with the rest of the Neutron core reviewers.
 As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
 reviewer. Doug has been actively reviewing code across not only all the 
 Neutron projects, but also other projects such as infra. His help and work in 
 the services split in December were the reason we were so successful in 
 making that happen. Doug has also been instrumental in the Neutron LBaaS V2 
 rollout, as well as helping to merge code in the other neutron service 
 I'd also like to take this time to remind everyone that reviewing code is a 
 responsibility, in Neutron the same as other projects. And core reviewers are 
 especially beholden to this responsibility. I'd also like to point out that 
 +1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
 code even if you are not a core reviewer.
 Existing neutron cores, please vote +1/-1 for the addition of Doug to the 
 core team.
 It's been a week, and Doug has received plenty of support. Welcome to the 
 Neutron Core Review team Doug!

Welcome Doug!


OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [Neutron] UniqueConstraint for name and tenant_id in security group

2014-12-11 Thread Mark McClain

 On Dec 11, 2014, at 8:43 AM, Jay Pipes wrote:
 I'm generally in favor of making name attributes opaque, utf-8 strings that 
 are entirely user-defined and have no constraints on them. I consider the 
 name to be just a tag that the user places on some resource. It is the 
 resource's ID that is unique.
 I do realize that Nova takes a different approach to *some* resources, 
 including the security group name.
 End of the day, it's probably just a personal preference whether names should 
 be unique to a tenant/user or not.
 Maru had asked me my opinion on whether names should be unique and I answered 
 my personal opinion that no, they should not be, and if Neutron needed to 
 ensure that there was one and only one default security group for a tenant, 
 that a way to accomplish such a thing in a race-free way, without use of 
 SELECT FOR UPDATE, was to use the approach I put into the pastebin on the 
 review above.

I agree with Jay.  We should not care about how a user names the resource.  
There other ways to prevent this race and Jay’s suggestion is a good one.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] mid-cycle update

2014-12-11 Thread Mark McClain

 On Dec 11, 2014, at 10:29 AM, Kyle Mestery wrote:
 On Wed, Dec 10, 2014 at 5:41 PM, Michael Still wrote:
 This all sounds like good work. Did you manage to progress the
 nova-network to neutron migration tasks as well?
 I forgot to mention that, but yes, there was some work done on that as well. 
 I'll follow up with Oleg on this. Michael, I think it makes sense for us to 
 discuss this in an upcoming Neutron meeting as well. I'll figure out a time 
 and let you know. Having some nova folks there would be good.

Oleg and I sat down at the mid-cycle and worked through the design spec more.  
He’s working through the spec draft to validate a few bits of the spec to make 
sure they’re doable.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Changes to the core team

2014-12-02 Thread Mark McClain

 On Dec 2, 2014, at 10:59 AM, Kyle Mestery wrote:
 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.

Thanks to Bob and Nachi for all of their hard work during the early cycles of 

 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.
 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.

+1 to Henry and Kevin.  They’ve both been great contributors the last few 
cycles and would make great cores.

OpenStack-dev mailing list

[openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-18 Thread Mark McClain

Over the last several months, the members of the Networking Program have been 
discussing ways to improve the management of our program.  When the Quantum 
project was initially launched, we envisioned a combined service that included 
all things network related.  This vision served us well in the early days as 
the team mostly focused on building out layers 2 and 3; however, we’ve run into 
growth challenges as the project started building out layers 4 through 7.  
Initially, we thought that development would float across all layers of the 
networking stack, but the reality is that the development concentrates around 
either layer 2 and 3 or layers 4 through 7.  In the last few cycles, we’ve also 
discovered that these concentrations have different velocities and a single 
core team forces one to match the other to the detriment of the one forced to 
slow down.

Going forward we want to divide the Neutron repository into two separate 
repositories lead by a common Networking PTL.  The current mission of the 
program will remain unchanged [1].  The split would be as follows:

Neutron (Layer 2 and 3)
- Provides REST service and technology agnostic abstractions for layer 2 and 
layer 3 services.

Neutron Advanced Services Library (Layers 4 through 7)
- A python library which is co-released with Neutron
- The advance service library provides controllers that can be configured to 
manage the abstractions for layer 4 through 7 services.

Mechanics of the split:
- Both repositories are members of the same program, so the specs repository 
would continue to be shared during the Kilo cycle.  The PTL and the drivers 
team will retain approval responsibilities they now share. 
- The split would occur around Kilo-1 (subject to coordination of the Infra and 
Networking teams). The timing is designed to enable the proposed REST changes 
to land around the time of the December development sprint.
- The core team for each repository will be determined and proposed by Kyle 
Mestery for approval by the current core team.
- The Neutron Server and the Neutron Adv Services Library would be co-gated to 
ensure that incompatibilities are not introduced.
- The Advance Service Library would be an optional dependency of Neutron, so 
integrated cross-project checks would not be required to enable it during 
- The split should not adversely impact operators and the Networking program 
should maintain standard OpenStack compatibility and deprecation cycles.

This proposal to divide into two repositories achieved a strong consensus at 
the recent Paris Design Summit and it does not conflict with the current 
governance model or any proposals circulating as part of the ‘Big Tent’ 

Kyle and mark

OpenStack-dev mailing list

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-18 Thread Mark McClain

 On Nov 18, 2014, at 5:45 PM, Doug Hellmann wrote:
 There would not be a service or REST API associated with the Advanced 
 Services code base? Would the REST API to talk to those services be part of 
 the Neutron repository?

We had considered having a standalone REST service, but the Advance Services 
need a level of integration with Neutron that is more than REST and RPC can 
provide.  So the initial plan is to have the operator configure the Neutron 
REST service to load the appropriate Advance Service controller modules.  This 
would enable the operators to continue to deploy a single endpoint and preserve 
existing user tools.

The integration interface would be formalized as part of the current 
refactoring work being completed during the Kilo cycle.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron][advanced services] Weekly IRC meeting day/time change

2014-11-10 Thread Mark McClain

 On Nov 9, 2014, at 11:14 PM, Sumit Naiksatam wrote:
 Hi All,
 Following up from the discussions during the Kilo Summit, we will be
 resuming the Advanced Services' meetings [1]. The new day/time will be
 Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting

-1 to starting meeting this week

This item affects the entire project and should be discussed in the main 
meeting when they resume.  Holding this meeting in a vacuum is counter 
productive as it will not actually serve to prepare for the split since the 
principals will not be in attendance.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][Spec freeze exception] Rootwrap daemon ode support

2014-11-10 Thread Mark McClain

 On Nov 7, 2014, at 5:52 AM, Miguel Ángel Ajo wrote:
 Ohh, sad to hear that Yuriy, you were doing an awesome work. I will take some 
 time to re-review the final state of the code and specs, and move it forward. 
 Thank you very much for your contribution.
 Miguel Ángel Ajo
 Sent with Sparrow

Thanks for resuming this work.  I’m glad we’ll able to leverage Yuriy’s 
contribution and hopefully merge this early in the cycle.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Limitation of permissions on modification some resources

2014-09-29 Thread Mark McClain

On Sep 29, 2014, at 7:09 AM, Andrey Epifanov wrote:

 Hi All,
 I started working on the the
 and realized that we have the same issue with other connected resources in 

The is a bug in how we’re implementing the logic to manage routes on the router 
instance in the l3-agent implementation.  There are other implementations of 
the logical router that do not need this restriction. 

 The problem is that we have API for the modification of any resources without
 limitations, for example, we can modify Router IP and connected to this subnet
 VMs never will know about it and lose the default router. The same situation
 with routes and IP for DHCP/DNS ports.

I don’t see any of these as a bug.  If tenant wants to make changes to their 
network (even ill advised ones), we should allow it.  Restricting these API 
operations to admin’s means we’re inhibiting users from making changes that 
could be regular maintenance operations of a tenant.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] [IPv6] New API format for extra_dhcp_opts

2014-09-26 Thread Mark McClain

On Sep 26, 2014, at 2:39 AM, Xu Han Peng wrote:

 Currently the extra_dhcp_opts has the following API interface on a port:
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value:, opt_name: tftp-server},
 {opt_value:, opt_name: server-ip-address}
 During the development of DHCPv6 function for IPv6 subnets, we found this 
 format doesn't work anymore because an port can have both IPv4 and IPv6 
 address. So we need to find a new way to specify extra_dhcp_opts for DHCPv4 
 and DHCPv6, respectively. (
 Here are some thoughts about the new format:
 Option1: Change the opt_name in extra_dhcp_opts to add a prefix (v4 or v6) so 
 we can distinguish opts for v4 or v6 by parsing the opt_name. For backward 
 compatibility, no prefix means IPv4 dhcp opt. 
 extra_dhcp_opts: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value:, opt_name: v4:tftp-server},
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 Option2: break extra_dhcp_opts into IPv4 opts and IPv6 opts. For backward 
 compatibility, both old format and new format are acceptable, but old format 
 means IPv4 dhcp opts. 
 extra_dhcp_opts: {
  ipv4: [
 {opt_value: testfile.1,opt_name: bootfile-name},
 {opt_value:, opt_name: 
  ipv6: [
 {opt_value: [2001:0200:feed:7ac0::1], opt_name: 
 The pro of Option1 is there is no need to change API structure but only need 
 to add validation and parsing to opt_name. The con of Option1 is that user 
 need to input prefix for every opt_name which can be error prone. The pro of 
 Option2 is that it's clearer than Option1. The con is that we need to check 
 two formats for backward compatibility. 
 We discussed this in IPv6 sub-team meeting and we think Option2 is preferred. 
 Can I also get community's feedback on which one is preferred or any other 

I’m -1 for both options because neither is properly backwards compatible.  
Instead we should add an optional 3rd value to the dictionary: “version”.  The 
version key would be used to make the option only apply to either version 4 or 
6.  If the key is missing or null, then the option would apply to both. 


OpenStack-dev mailing list

Re: [openstack-dev] [nova] 2 weeks in the bug tracker

2014-09-23 Thread Mark McClain

On Sep 19, 2014, at 9:13 AM, Sean Dague wrote:

 Cross interaction with Neutron and Cinder remains racey. We are pretty
 optimistic on when resources will be available. Even the event interface
 with Neutron hasn't fully addressed this. I think a really great Design
 Summit session would be Nova + Neutron + Cinder to figure out a shared
 architecture to address this. I'd expect this to be at least a double


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][db] End of meetings for neutron-db

2014-09-22 Thread Mark McClain

On Sep 22, 2014, at 9:26 AM, Henry Gessau wrote:
 The work on healing and reorganizing Neutron DB migrations is complete, and so
 we will no longer hold meetings.

Great work by all who worked on this.  

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

2014-09-22 Thread Mark McClain

On Sep 22, 2014, at 1:20 PM, Monty Taylor wrote:

 On 09/21/2014 10:57 PM, Nader Lahouti wrote:
 Thanks Kevin for bring it up in the ML, I was looking for a guideline or
 any document to clarify issues on this subject.
 I was told, even using keystone API in neutron is not permitted.
 I recognize that I'm potentially without context for neutron internals -
 but could someone please shed some light on why using keystone API from
 neutron would ever be forbidden? That sounds a bit craycray to me and
 I'd like to understand more.

In the past, the proposed usage of the Keystone API for things other than auth 
have been craycray :) As a response, we’ve established an extremely high bar 
for those wishing to entangle the two. The proposals tradionatlly have Neutron 
acting as proxy for Keystone vs having the backend controller request the 
information directly creates more problems than it solves. I’m not opposed to 
altering our stance, but I’ve yet to see a proposal for a Keystone proxy that 
handles synchronization correctly outside the happy path test in a dev 

Ideally, I think something that provides proper sync support should exist in 
Keystone or a Keystone related project vs multiple implementations in Neutron, 
Cinder or any other multi-tenant service that wants to provide more human 
friendly names for a vendor backend.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Status of Neutron at Juno-3

2014-09-03 Thread Mark McClain

On Sep 3, 2014, at 11:04 AM, Brian Haley wrote:

 On 09/03/2014 08:17 AM, Kyle Mestery wrote:
 Given how deep the merge queue is (146 currently), we've effectively
 reached feature freeze in Neutron now (likely other projects as well).
 So this morning I'm going to go through and remove BPs from Juno which
 did not make the merge window. I'll also be putting temporary -2s in
 the patches to ensure they don't slip in as well. I'm looking at FFEs
 for the high priority items which are close but didn't quite make it:
 I guess I'll be the first to ask for an exception for a Medium since the code
 was originally completed in Icehouse:
 The neutronclient-side code was committed in January, and the neutron side, has had mostly positive reviews since
 then.  I've really just spent the last week re-basing it as things moved 

+1 for FFE.  I think this is good community that fell through the cracks.


OpenStack-dev mailing list

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

2014-08-28 Thread Mark McClain

On Aug 28, 2014, at 10:45 AM, Jay Pipes wrote:

 On 08/27/2014 04:28 PM, Kevin Benton wrote:
 What are you talking about? The only reply was from me clarifying that
 one of the purposes of the incubator was for components of neutron that
 are experimental but are intended to be merged.
 Right. The special unicorns.
  In that case it might
 not make sense to have a life cycle of their own in another repo
 The main reasons these experimental components don't make sense to live in 
 their own repo indefinitely are:
 a) Neutron's design doesn't make it easy or straightforward to build/layer 
 other things on top of it, or:

Correct and this something I want the team to address in Kilo.  Many of the L7 
services would be easier to build if we invest some time early in the cycle to 
establishing a well defined interface for a few items.  I’m sure the LBaaS team 
has good feedback to share with everyone.

 b) The experimental piece of code intends to replace whole-hog a large chunk 
 of Neutron's existing codebase, or:
 c) The experimental piece of code relies so heavily on inconsistent, 
 unversioned internal interface and plugin calls that it cannot be designed 
 externally due to the fragility of those interfaces

I’m glad Jim reminded us of the pain of merging histories and the availability 
of feature branches.  I think for items where we’re replacing large chunks of 
code feature branches make lots of sense.

 Fixing a) is the solution to these problems. An incubator area where 
 experimental components can live will just continue to mask the true 
 problem domain, which is that Neutron's design is cumbersome to build on top 
 of, and its cross-component interfaces need to be versioned, made consistent, 
 and cleaned up to use versioned data structures instead of passing random 
 nested dicts of randomly-prefixed string key/values.
 Frankly, we're going through a similar problem in Nova right now. There is a 
 group of folks who believe that separating the nova-scheduler code into the 
 Gantt project will magically make placement decision code and solver 
 components *easier* to work on (because the pace of coding can be increased 
 if there wasn't that pesky nova-core review process). But this is not 
 correct, IMO. Separating out the scheduler into its own project before 
 internal interfaces and data structures are cleaned up and versioned will 
 just lead to greater technical debt and an increase in frustration on the 
 part of Nova developers and scheduler developers alike.

Right hopefully the incubator will allow us to develop components that should 
be independent from the start without incurring too much debt.

 On Wed, Aug 27, 2014 at 11:52 AM, Jay Pipes wrote:
On 08/26/2014 07:09 PM, James E. Blair wrote:
After reading I have
some thoughts about the proposed workflow.
We have quite a bit of experience and some good tools around
code out of projects and into new projects.  But we don't
generally do a
lot of importing code into projects.  We've done this once, to my
recollection, in a way that preserved history, and that was with the
switch to keystone-lite.
It wasn't easy; it's major git surgery and would require significant
infra-team involvement any time we wanted to do it.
However, reading the proposal, it occurred to me that it's
pretty clear
that we expect these tools to be able to operate outside of the
project itself, to even be releasable on their own.  Why not
just stick
with that?  In other words, the goal of this process should be
to create
separate projects with their own development lifecycle that will
continue indefinitely, rather than expecting the code itself to
into the neutron repo.
This has advantages in simplifying workflow and making it more
consistent.  Plus it builds on known integration mechanisms like
and python project versions.
But more importantly, it helps scale the neutron project itself.  I
think that a focused neutron core upon which projects like these can
build on in a reliable fashion would be ideal.
Despite replies to you saying that certain branches of Neutron
development work are special unicorns, I wanted to say I *fully*
support your above statement.
OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Author tags

2014-08-27 Thread Mark McClain

On Aug 27, 2014, at 2:27 PM, Mandeep Dhami wrote:

T hese should all be comment changes, so there should be no impact. While I 
agree that it is late for J3, IMO this is the type of change (minor/comment 
only) that should be OK J4 rather than wait for Kilo.

We do not have a J4 milestone :)  That said we’ve accumulated a bunch of rebase 
generating very low risk code cleanup items.  I’ve been maintaining a list of 
these for team consideration as the final item during the freeze period.


On Wed, Aug 27, 2014 at 7:25 AM, Kyle Mestery wrote:
On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton wrote:
 A few cycles ago the Nova group decided to remove @author from copyright
 statements. This is due to the fact that this information is stored in git.
 After adding a similar hacking rule to Neutron it has stirred up some
 Does anyone have any reason to for us not to go ahead with

My main concern is around landing a change like this during feature
freeze week, I think at best this should land at the start of Kilo.

 OpenStack-dev mailing list

OpenStack-dev mailing list

OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][QA] Enabling full neutron Job

2014-08-15 Thread Mark McClain

On Aug 15, 2014, at 6:20 PM, Salvatore Orlando wrote:

The neutron full job is finally voting, and the first patch [1] has already 
passed it in gate checks!
I've collected a few data points before it was switched to voting, and we 
should probably expect a failure rate around 4%. This is not bad, but neither 
great, and everybody's contribution will be appreciated in reporting and 
assessing the nature gate failures, which, needless to say, are mostly races.

Note: we've also added the postgresql version of the same job, but that is not 
voting yet as we never executed it before.



Thanks to Salvatore for driving this effort and for everyone who contributed 
patches and reviews.  It is exciting to see it enabled.


OpenStack-dev mailing list

[openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-04 Thread Mark McClain


* Group Based Policy API is the kind of experimentation we be should attempting.
* Experiments should be able to fail fast.
* The master branch does not fail fast.
* StackForge is the proper home to conduct this experiment.

Why this email?
Our community has been discussing and working on Group Based Policy (GBP) for 
many months.  I think the discussion has reached a point where we need to 
openly discuss a few issues before moving forward.  I recognize that this 
discussion could create frustration for those who have invested significant 
time and energy, but the reality is we need ensure we are making decisions that 
benefit all members of our community (users, operators, developers and vendors).


I like that as a community we are exploring alternate APIs.  The process of 
exploring via real user experimentation can produce valuable results.  A good 
experiment should be designed to fail fast to enable further trials via rapid 

Merging large changes into the master branch is the exact opposite of failing 

The master branch deliberately favors small iterative changes over time.  
Releasing a new version of the proposed API every six months limits our ability 
to learn and make adjustments.

In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs.  The 
results have been very mixed as operators either shy away from testing/offering 
the API or embrace the API with the expectation that the community will provide 
full API support and migration.  In both cases, the experiment fails because we 
either could not get the data we need or are unable to make significant changes 
without accepting a non-trivial amount of technical debt via migrations or 
draft API support.

Next Steps
Previously, the GPB subteam used a Github account to host the development, but 
the workflows and tooling do not align with OpenStack's development model. I’d 
like to see us create a group based policy project in StackForge.  StackForge 
will host the code and enable us to follow the same open review and QA 
processes we use in the main project while we are developing and testing the 
API. The infrastructure there will benefit us as we will have a separate review 
velocity and can frequently publish libraries to PyPI.  From a technical 
perspective, the 13 new entities in GPB [1] do not require any changes to 
internal Neutron data structures.  The docs[2] also suggest that an external 
plugin or service would work to make it easier to speed development.

End State
APIs require time to fully bake and right now it is too early to know the final 
outcome.  Using StackForge will allow the team to retain all of its options 
including: merging the code into Neutron, adopting the repository as 
sub-project of the Network Program, leaving the project in StackForge project 
or learning that users want something completely different.  I would expect 
that we'll revisit the status of the repo during the L or M cycles since the 
Kilo development cycle does not leave enough time to experiment and iterate.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][policy] Long standing -2 on Group-based policy patch

2014-08-04 Thread Mark McClain

On Aug 4, 2014, at 1:16 PM, Sumit Naiksatam wrote:

 The first patch[1] of this high priority approved blueprint[2][3]
 targeted for Juno-3 has been blocked by a core reviewer’s (Mark
 McClain) -2 since July 2nd. This patch was at patch-set 13 then, and
 has been repeatedly reviewed and updated to the current patch-set 22.
 However, there has been no comment or reason forthcoming from the
 reviewer on why the -2 still persists. The dependent patches have also
 gone through numerous iterations since.
 There is a team of several people working on this feature across
 different OpenStack projects since Oct 2013. The feature has been
 discussed and iterated over weekly IRC meetings[4], design sessions
 spanning two summits, mailing list threads, a working PoC
 implementation, and a code sprint. Blocking the first patch required
 for this feature jeopardizes this year-long effort and the delivery of
 this feature in Juno. For many, this may sound like an all too
 familiar story[5], and hence this team would like to mitigate the
 issue while there is still time.
 Mark, can you please explain why your -2 still persists? If there are
 no major outstanding issues, can you please remove the -2?

There are issues outside of the code itself, I’ve created a thread here to 

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Not support dnsmasq 2.63?

2014-07-30 Thread Mark McClain
The hard limit should be 2.63 since that is supported in all of the modern long 
term releases from the distros.  I’d prefer we not exit processes because we’ve 
been removing active checks on process starts.


On Jul 29, 2014, at 9:51 PM, Xuhan Peng wrote:

We bumped the minimum version of dnsmasq to 2.63 a while ago by this code 

However, currently we still kind of support earlier version of dnsmasq 
because we only give a warning and don't exit the program when we find dnsmasq 
version is less than the minimum version. This causes some confusion and 
complicates the code since we need to take care different syntax of dnsmasq of 
different version in dhcp code (Note that the previous version doesn't support 

I wonder what's your opinion on NOT supporting dnsmasq version less than 2.63 
in Juno? I think we can prompt error message and exit the program when we 
detect invalid version but I would like to gather more thoughts on this one.

Xu Han
OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] topics for Thurday's Weekly LBaaS meeting's agenda

2014-07-08 Thread Mark McClain

On Jul 8, 2014, at 9:57 AM, Susanne Balle wrote:

 I would like to discuss what talks we plan to do at the Paris' summit and who 
 will be submitting what? The deadline for submitting talks is July 28 so it 
 is approaching.
 Also how many working sessions do we need? and what prep work do we need to 
 do before the summit.
 I am personally interested in co-presenting a talk on Octavia and operator 
 requirements with Stephen and who else wants to contribute.


The 28th deadline is proposals to talk during the Conference portion.  Design 
summit sessions will be scheduled much later.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend

2014-07-07 Thread Mark McClain

On Jul 4, 2014, at 5:27 PM, Brandon Logan wrote:

 Hi German,
 That actually brings up another thing that needs to be done.  There is
 no DELETED state.  When an entity is deleted, it is deleted from the
 database.  I'd prefer a DELETED state so that should be another feature
 we implement afterwards.

This is an interesting discussion since we would create an API inconsistency 
around possible status values.  Traditionally, status has been be fabric status 
and we have not always well defined what the values should mean to tenants.  
Given that this is an extension, I think that adding new values would be ok 
(Salvatore might have a different opinion than me).

Right we’ve never had a deleted state because the record has been removed 
immediately in most implementations even if the backend has not fully cleaned 
up.  I was thinking for the v3 core we should have a DELETING state that is set 
before cleanup is dispatched to the backend driver/worker.  The record can then 
be deleted when the backend has cleaned up.

For unattached objects, I’m -1 on QUEUED because some will interpret that the 
system is planning to execute immediate operations on the resource (causing 
customer queries/complaints about why it has not transitioned).  Maybe use 
something like DEFERRED, UNBOUND, or VALIDATED? 

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Flavor framework: Conclusion

2014-07-07 Thread Mark McClain

On Jul 4, 2014, at 1:09 AM, Eugene Nikanorov wrote:


First of all extension list looks lbaas-centric right now.

Actually far from it.  SSL VPN should be service extension.

Secondly, TLS and L7 are such APIs which objects should not require 
loadbalancer or flavor to be created (like pool or healthmonitor that are pure 
db objects).
Only when you associate those objects with loadbalancer (or its child objects), 
driver may tell if it supports them.
Which means that you can't really turn those on or off, it's a generic API.

The driver should not be involved.  We can use the supported extensions to 
determine is associated logical resources are supported.  Otherwise driver 
behaviors will vary wildly.  Also deferring to driver exposes a possible way 
for a tenant to utilize features that may not be supported by the operator 
curated flavor.

From user perspective flavor description (as interim) is sufficient to show 
what is supported by drivers behind the flavor.

Supported extensions are critical component for this.

Also, I think that turning extensions on/off is a bit of side problem to a 
service specification, so let's resolve it separately.


On Fri, Jul 4, 2014 at 3:07 AM, Eichberger, German wrote:
I am actually a bit bummed that Extensions are postponed. In LBaaS we are 
working hard on L7 and TLS extensions which we (the operators) like to switch 
on and off with different flavors...


-Original Message-
From: Kyle Mestery 
Sent: Thursday, July 03, 2014 2:00 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Flavor framework: Conclusion

Awesome, thanks for working on this Eugene and Mark! I'll still leave an item 
on Monday's meeting agenda to discuss this, hopefully it can be brief.


On Thu, Jul 3, 2014 at 10:32 AM, Eugene Nikanorov wrote:

 Mark and me has spent some time today discussing existing proposals
 and I think we got to a consensus.
 Initially I had two concerns about Mark's proposal which are
 - extension list attribute on the flavor
 - driver entry point on the service profile

 The first idea (ext list) need to be clarified more as we get more
 drivers that needs it.
 Right now we have FWaaS/VPNaaS which don't have extensions at all and
 we have LBaaS where all drivers support all extensions.
 So extension list can be postponed until we clarify how exactly we
 want this to be exposed to the user and how we want it to function on
 implementation side.

 Driver entry point which implies dynamic loading per admin's request
 is a important discussion point (at least, previously this idea
 received negative opinions from some cores) We'll implement service
 profiles, but this exact aspect of how driver is specified/loadede
 will be discussed futher.

 So based on that I'm going to start implementing this.
 I think that implementation result will allow us to develop in
 different directions (extension list vs tags, dynamic loading and
 such) depending on more information about how this is utilized by deployers 
 and users.


 On Thu, Jul 3, 2014 at 5:57 PM, Susanne Balle wrote:


 On Wed, Jul 2, 2014 at 10:12 PM, Kyle Mestery

 We're coming down to the wire here with regards to Neutron BPs in
 Juno, and I wanted to bring up the topic of the flavor framework BP.
 This is a critical BP for things like LBaaS, FWaaS, etc. We need
 this work to land in Juno, as these other work items are dependent on it.
 There are still two proposals [1] [2], and after the meeting last
 week [3] it appeared we were close to conclusion on this. I now see
 a bunch of comments on both proposals.

 I'm going to again suggest we spend some time discussing this at the
 Neutron meeting on Monday to come to a closure on this. I think
 we're close. I'd like to ask Mark and Eugene to both look at the
 latest comments, hopefully address them before the meeting, and then
 we can move forward with this work for Juno.

 Thanks for all the work by all involved on this feature! I think
 we're close and I hope we can close on it Monday at the Neutron meeting!


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] validation of input against column-size specified in schema

2014-06-25 Thread Mark McClain

On Jun 25, 2014, at 12:26 AM, Manish Godara wrote:
 Is there any way in current neutron codebase that can be used to validate
 the length of a string attribute against the max column size specified in
 the schema for that attribute.
 E.g. , in
 class Network(model_base.BASEV2, HasId, HasTenant):
Represents a v2 neutron network.
name = sa.Column(sa.String(255))
 And if I want to validate the 'name' before storing in db, then how can I
 get the max allowable length given this definition?  I don't see any such
 validations being done in neutron for fields, so wondering how to do it.
 Maybe it's there and I missed it.

There’s not any length validation currently as the original v2 API spec never 
specified the max field length.  One of the changes being made as part of the 
REST layer refactoring is that we’re adding length validation.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] High bandwidth routers

2014-06-24 Thread Mark McClain

On Jun 23, 2014, at 9:21 AM, CARVER, PAUL wrote:

Is anyone using Neutron for high bandwidth workloads? (for sake of discussion 
let’s “high” = “50Gbps or greater”)

With routers being implemented as network namespaces within x86 servers it 
seems like Neutron networks would be pretty bandwidth constrained relative to 
“real” routers.

As we start migrating the physical connections on our physical routers from 
multiple of 10G to multiples of 100G, I’m wondering if Neutron has a clear 
roadmap towards networks where the bandwidth requirements exceed what an x86 
box can do.

Is the thinking that x86 boxes will soon be capable of 100G and multi-100G 
throughput? Or does DVR take care of this by spreading the routing function 
over a large number of compute nodes so that we don’t need to channel 
multi-100G flows through single network nodes?

I’m mostly thinking about WAN connectivity here, video and big data 
applications moving huge amounts of traffic into and out of OpenStack based 

There are few internal implementations of the l3 plugin that are backed by 
dedicated hardware vs commodity+network namespaces.  Of those few, all are site 
specific (due to limited feature support and not likely to upstreamed).


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Core API refactoring

2014-05-21 Thread Mark McClain

On May 21, 2014, at 10:23 AM, Mandeep Dhami wrote:

Hi Sean:

While the APIs might not be changing*, I suspect that there are significant 
design decisions being made**. These changes are probably more significant than 
any new feature being discussed. As a community, are we expected to document 
these design changes and review these changes as well?

There was a bit of high level discussion needed to ensure community consensus 
before we could dive into the details.  The actual changes will be documented 
according to Neutron’s spec process.

I am still trying to figure out what Neutron's review standards are. On one 
hand, I am seeing code review comments that reject a patch for cosmetic changes 
(like a name change from what was in the reviewed blueprint), to having an 
attitude that something as core and central to neutron as refactoring and a 
major API update to v3 not needing a design document/review.

It is my opinion, and my recommendation, that the proposed changes be 
documented and reviewed by same standard that we have for other features.

That has been the plan all along to follow the spec process as with all other 
changes to Neutron.

* I believe that v3 API is being introduced and chnages are being made, but I 
might have mis-understood.

It is important to note that the changes are to the code level interfaces 
within the neutron-server executable and no user facing REST changes.  The 
intent is to keep compatibility with existing V2 plugins while moving towards a 
new V3 plugin architecture.  Our dev cycle is really short, so inserting this 
new layer will be in preparation for a formal V3 definition declared during the 
K cycle.  The discussion intentionally avoided any changes to logical and/or db 
models for this very reason.

** I was under the impression that in addition to the Pecan updates, there was 
going to be refactoring to use taskflow as well. And that I expect to have 
significant control flow impact, and that is what I really wanted to review.

Moving towards tasks is actually independent of the changes to the REST layer.  
Tasks will refactor the implementation of the actual plugins, but should not 
require any cooperation with the REST layer.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Proposed changes to core team

2014-05-21 Thread Mark McClain

On May 21, 2014, at 4:59 PM, Kyle Mestery wrote:

 Neutron cores, please vote +1/-1 for the proposed addition of Carl
 Baldwin to Neutron core.

Carl has been a great contributor. +1 to adding to core team


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS][FWaaS][VPNaaS] Advanced Services (particularly LBaaS) and Neutron

2014-05-07 Thread Mark McClain

On May 7, 2014, at 7:45 AM, Susanne Balle wrote:

Based on discussions with Rackspace, Mirantis, and others it is clear that the 
advanced services (i.e. LBaaS) in Neutron are not getting the attention and the 
support to move forward and create a first in class load-balancer service; from 
a service provider or operator's perspective. We currently have a lot of 
momentum and energy behind the LBaaS effort but are being told that the focus 
for Neutron is bug fixing given the instability in Neutron itself. While the 
latter is totally understandable, as a high priority for Neutron it leaves the 
advanced services out in the cold
The only reason the advance services team would be out in the cold is that 
members actively choose not to participate in the broader community.  The code, 
bugs, and reviews are open so contributing more devs resources for the 
stability fixes would have improved the velocity of stability improvements.

Some of the background reasoning for suggesting this is available at:

I’ve added comment there to provide additional information, but I do not think 
splitting these out are in the best interest of the community because of the 
logistical and technical problems it creates.  I’d rather see a deeper 
participation in the broader Neutron community.
Hope to see you there to discuss how we best make sure that the advanced 
services can support the many companies that rely on LBaaS or other advanced 
services for large scale deployment.

Look forward to discussing this,

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-04 Thread Mark McClain

 On May 4, 2014, at 8:08, Sean Dague wrote:
 Question (because I honestly don't know), when would you want more than
 1 l3 agent running on the same box?

For the legacy case where there are multiple external networks connected to a 
node on different bridges.
OpenStack-dev mailing list

Re: [openstack-dev] [neutron] explanations on the current state of config file handling

2014-05-02 Thread Mark McClain

On May 2, 2014, at 7:39 AM, Sean Dague wrote:

 Some non insignificant number of devstack changes related to neutron
 seem to be neutron plugins having to do all kinds of manipulation of
 extra config files. The grenade upgrade issue in neutron was because of
 some placement change on config files. Neutron seems to have *a ton* of
 config files and is extremely sensitive to their locations/naming, which
 also seems like it ends up in flux.

We have grown in the number of configuration files and I do think some of the 
design decisions made several years ago should probably be revisited.  One of 
the drivers of multiple configuration files is the way that Neutron is 
currently packaged [1][2].  We’re packaged significantly different than the 
other projects so the thinking in the early years was that each plugin/service 
since it was packaged separately needed its own config file.  This causes 
problems because often it involves changing the init script invocation if the 
plugin is changed vs only changing the contents of the init script.  I’d like 
to see Neutron changed to be a single package similar to the way Cinder is 
packaged with the default config being ML2.

 Is there an overview somewhere to explain this design point?

Sadly no.  It’s a historical convention that needs to be reconsidered.

 All the other services have a single config config file designation on
 startup, but neutron services seem to need a bunch of config files
 correct on the cli to function (see this process list from recent
 grenade run - note you will have
 to horiz scroll for some of the neutron services).
 Mostly it would be good to understand this design point, and if it could
 be evolved back to the OpenStack norm of a single config file for the

+1 to evolving into a more limited set of files.  The trick is how we 
consolidate the agent, server, plugin and/or driver options or maybe we don’t 
consolidate and use config-dir more.  In some cases, the files share a set of 
common options and in other cases there are divergent options [3][4].   Outside 
of testing the agents are not installed on the same system as the server, so we 
need to ensure that the agent configuration files should stand alone.  

To throw something out, what if moved to using config-dir for optional configs 
since it would still support plugin scoped configuration files.  

Neutron Servers/Network Nodes
neutron.conf  (Common Options)
server.d (all plugin/service config files )
service.d (all service config files)

Hypervisor Agents
agent.d (Individual agent config files)

The invocations would then be static:

neutron-server —config-file /etc/neutron/neutron.conf —config-dir 

Service Agents:
neutron-l3-agent —config-file /etc/neutron/neutron.conf —config-dir 

Hypervisors (assuming the consolidates L2 is finished this cycle):
neutron-l2-agent —config-file /etc/neutron/neutron.conf —config-dir 



OpenStack-dev mailing list

Re: [openstack-dev] [neutron] status of VPNaaS and FWaaS APIs in Icehouse

2014-04-24 Thread Mark McClain

On Apr 23, 2014, at 6:20 PM, McCann, Jack wrote:

 Are VPNaaS and FWaaS APIs still considered experimental in Icehouse?
 For VPNaaS, [1] says This extension is experimental for the Havana release.
 For FWaaS, [2] says The Firewall-as-a-Service (FWaaS) API is an experimental 

Thanks for asking.  Both should still be considered experimental because of the 
multivendor work was completed in Icehouse.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Flavor(?) Framework

2014-04-23 Thread Mark McClain

On Apr 23, 2014, at 11:05 AM, Eugene Nikanorov wrote:

 Hi neutrons,
 A quick question of the ^^^
 I heard from many of you that a term 'flavor' is undesirable, but so far 
 there were no suggestions for the notion that we are going to introduce.

Why is flavor undesirable?  The terminology parallels meaning from elsewhere in 
OpenStack and this is first objection that I’ve heard to the usage of this 
term.  Whenever I’ve had this discussion with folks outside of the Neutron they 
readily understand the concept.  What do others find wrong with this term?


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Service VMs

2014-04-21 Thread Mark McClain

On Apr 21, 2014, at 3:07 PM, Kyle Mestery wrote:

 For the upcoming Summit there are 3 sessions filed around Service
 VMs in Neutron. After discussing this with a few different people,
 I'd like to propose the idea that the Service VM work be moved out
 of Neutron and into it's own project on stackforge. There are a few
 reasons for this:
 1. There is nothing Neutron specific about service VMs.

Agreed.  VMs are one of several options for implementing a service.  Managing 
the full lifecycle tends to touch on lots of OpenStack components and as Kyle 
wrote below there is nothing to specific to Neutron about them.

 2. Service VMs can perform services for other OpenStack projects.
 3. The code is quite large and may be better served being inside it's
 own project.
 Moving the work out of Neutron and into it's own project would allow
 for separate velocity for this project, and for code to be shared for
 the Service VM work for things other than Neutron services.
+1 to starting a separate project on stackforge for this work.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Trying to make sense of allow_overlapping_ips in neutron

2014-04-18 Thread Mark McClain

On Apr 18, 2014, at 17:03, Ryan Moats wrote:

Apologies if this is posted to the wrong place, but after talking with Kyle 
Mestery (, he suggested that I 
bring my question here...

I'm trying to make sense of the allow_overlapping_ips configuration parameter 
in neutron.

When this entry is true, then a tenant can have subnets with overlapping IPs in 
different networks (i.e. the scope of the subnet validation search is the other 
subnets associated with the network) which makes sense.

But, when this entry is false, then the validation search appears to cover all 
subnets across all tenants.  I'm trying to understand the logic of this, 
because I would have expected that in this case, the search scope would be all 
subnets across a single tenant.

As it is now, it looks like if an install has this configuration parameter set 
to false, then there is no way for that install to reuse the net 10 address 

Can somebody lend me a hand and either (a) tell me I'm reading the code wrong 
or (b) explain why that choice was made?

You are reading the code correctly. This feature is largely a legacy option for 
older distros that do not support namespaces or when the deployer chooses to 
run in a flat mode without tenant isolation.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Migrations, service plugins and Grenade jobs

2014-04-15 Thread Mark McClain

On Apr 14, 2014, at 11:54 AM, Salvatore Orlando wrote:

1) Specify that all migrations must run for every plugin (*) unless they are 
really introducing schemas which are specific to a particular technology (such 
as uuid mappings between neutron and backed)

This approach will probably ensure all the important migrations are executed.
However, it is not back portable, unless deployers decide to tear down and 
rebuild their databases from scratch, which is unlikely to happen.

To this aim recovery scripts might be provided to sync up the schema state of 
specific service plugins with the current alembic migration registered in the 
neutron database; or appropriate migrations can be added in the path to fix 
database schemas.

(*) Neutron does not address, and probably never will address, switching from 
plugin a to b for a given service (e.g.: core features).

This option has several additional problems because of the way plugins/drivers 
are conditionally imported and packaged.  As a result, auto generation of 
schema (inadvertent drop for schema) or even validation of existing models vs 
the the migration will fail because models are not imported unless part of the 


OpenStack-dev mailing list

[openstack-dev] TC Candidacy

2014-04-14 Thread Mark McClain

I'd like to announce my candidacy to continue serving on the Technical 

OpenStack is one community comprised of many parts and we must view ourselves 
as one unit. As a TC member, I will continue to place the interests of the 
larger community over those of those of individual projects.

There are several key areas I'd like to see the TC focus on:

The Technical Committee should serve as a high level forum to 
facilitate defining cross project technical and procedural requirements. While 
many of our programs share commonalities, there are still differences in 
policies and technical decisions. The TC should continue its work to build 
consensus and reduce the differences between the projects so the community can 
function as one body.  

Cross Project Communication
Cross project communication is essential to maintaining a unified 
stable OpenStack release.  When serving as PTL, I worked to facilitate a 
mid-cycle meetup specifically designed to increase interaction between QA and 
Networking teams.  I believe the TC should promote similar cross-project 
initiatives where deep collaboration enhances the unity of our community.

A recurring theme during the most recent term of the TC has been the 
refinement of our program and project maturation process. The committee needs 
to continue this work as it clarifies and strengthens the criteria used to 
determine the kind of projects and programs that fit within the scope of 
integrated releases and how they move through the progression of incubation to 
graduation.  The growth of our community project ecosystem is very exciting, 
but we’re currently limited in our ability to scale the number of incubated 
projects.  The TC should examine how we can better scale the number of 
incubated projects while ensuring a successful integration into the release 

Unified Experience
For OpenStack to be successful we must strive to provide a unified 
experience for both users and deployers.  Users want tools that are well 
documented and easy to use. The documentation and tools must be portable across 
deployments (both public and private) so that users do not need to concern 
themselves with the implementation details. At the same time, deployers should 
be able to upgrade between releases and maintain a known level of 
compatibility. Our community has invested significant effort to improve this 
experience and this should remain a focus going forward.

About Me
I am currently a member of the Technical Committee and a former PTL. Believing 
that OpenStack is a unified community, I have contributed code and reviews to 
nearly all of our integrated projects since my first contribution during the 
Essex cycle. I believe that cross project contributions are essential to foster 
collaboration and sharing of ideas within our community. I'm a member of the 
Stable Release Team and the Requirements Team. My work on both teams provides a 
cross project view of our community with an eye towards stability and 
consistency.  Outside of development, I travel extensively to advocate and 
educate on OpenStack and interact with our community of developers, deployers 
and users.

We have built a very special open community through the contributions of many.  
These contributions have powered our phenomenal growth and I'm excited about 
our future!

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] DHCP address being SNAT by L3 agent

2014-04-08 Thread Mark McClain

On Apr 8, 2014, at 3:58 AM, Xuhan Peng wrote:

 Hi Neutron stackers,
 I have a question about how to fix the problem of DHCP port address being 
 SNAT by L3 agent. 
 I have my neutron DHCP agent and L3 agent running on the same network node, 
 and I disabled namespace usage in both agent configuration. I have one router 
 created with one external network and one internal network attached. 

Running the L3 Agent and DHCP Agent on the same node with namespaces disabled 
is not a supported configuration for many reasons.  This was previously in the 
manuals, I’ll double check to make sure was not inadvertently dropped during 
the documentation reorganization.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Release Notes for Icehouse

2014-04-04 Thread Mark McClain

On Apr 4, 2014, at 11:03 AM, Yaguang Tang wrote:

I think it's important for our developers to publish an official Release Note 
as other core openstack projects does at the end of Icehouse development cycle, 
it contains the new features added and upgrade issue to be noticed by the 
users. any one like to be volunteer to help accomplish it?

I’ve typically waited until after we publish the second RC to add release notes 
to the Wiki. I’ll update the release notes for Neutron when we close out RC2.


OpenStack-dev mailing list

[openstack-dev] [Neutron] PTL Candidacy

2014-03-31 Thread Mark McClain

I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL and would like to continue leading our team during 
the Juno cycle.  As PTL, I have worked to promote a vibrant open ecosystem of 
deployers, integrators and vendors within Neutron.  Our openness is exemplified 
by the new drivers/plugins, new contributors, and diversity of sub team 
leadership in Icehouse.

I have been a contributor to Neutron since Essex and a core team member since 
Folsom.  I have been developing software with Python professionally for 14 
years and currently work for Yahoo!, a deployer of OpenStack.  Within the 
Neutron code base, I have worked extensively on DHCP, IP library, network 
namespaces, metadata services, database migrations, and LBaaS reference 
implementation.  I frequently present Neutron at local and regional OpenStack 
events to build community by engaging new developers, deployers, and 

I am the top reviewer during the Icehouse cycle:

I am the top reviewer since the inception of Neutron:


As the technical lead during Icehouse, I kicked off the initiative to improve 
testing within Neutron.  This initiative included the creation of the mid-cycle 
sprint that brought the QA and Neutron teams together.  The successful sprint  
produced a more stable Neutron core, more API test coverage, the soon-to-be 
enabled full Tempest and Grenade jobs and a more connected community.  
Additionally, I promoted the policy of improve 3rd party testing of 
plugin/driver code from vendors [1].  This initiative has resulted in a more 
thoroughly tested and stable driver/plugin codebase for operators to deploy.

My vision for Juno is that our team continue to build upon the open environment 
that enables all vendors, deployers and integrators the opportunity to 
contribute to the development of Neutron.  During the cycle, I believe our team 
should focus on a few core initiatives:

* Nova Parity
We committed to delivering Nova Parity when Neutron was accepted as an 
Integrated project.  By delivering Distributed Virtual Routing, Nova-Network to 
Neutron migration, testing and documentation we will be following through on 
our commitment to the greater OpenStack community.

* Advanced Services
The team should implement a multi-vendor ‘flavor' API that provides tenants an 
easy to use API, deployers a choice and vendors an opportunity to innovate.  
This API should complement the existing APIs our teams have created over the 
last two cycles.  Additionally, we should add secure APIs and agent code to 
support SSL termination for LBaaS and SSL VPNs.

* Process Improvements
Our team has grown, but our processes for submitting and reviewing blueprints 
has largely stayed the same which has made the review process uneven. As the 
Icehouse cycle has wound down, I have been working to put new infrastructure in 
place to improve the blueprint process for Juno[2].  The new process should 
ensure a more consistent experience for all contributors in Juno.  In addition 
to refining the blueprint process, our sub team structure should be revised to 
improve communication, remove blockers, and facilitate more efficient reviews.

* Internal API and REST API Improvements
We have several exciting new features in development for Neutron, but at times 
our internal APIs have inhibited efficient implementation of these features.  
During the Juno cycle, we should begin the process of revising our internal 
interfaces to enable easier IPv6, migration to Python 3 and development of 
plugins/drivers and services,

* Group Policy
There is significant community interest in adding policy support to Neutron.  
During Juno, we should work on implementing the first iteration of the policy 
API extension.  This extensions will be aided by the work to improve the 
internal API.

* Testing
The team made significant testing gains during Icehouse.  We should build on 
that work during Juno and collaborate with the QA team to further refine and 
improve our testing through additional scenarios, varied migration 
configurations and functional tests.

* Documentation
Good documentation is a requirement for both deployers and developers we have 
made improvements to both Icehouse.  For Juno, I’d like to continue this work 
as it is essential for parity.

* Growing our plugin and driver community

See something missing from this list?  As PTL, I’m excited to work with our 
community to refine this list for Juno.

Other OpenStack Contributions
* Co-organizer of the Atlanta OpenStack Meetup
* Member of the Technical Committee since the Havana cycle
* Stable Core Team Member
* Requirements Core Team Member



Re: [openstack-dev] Spec repos for blueprint development and review

2014-03-25 Thread Mark McClain

On Mar 24, 2014, at 2:23 PM, Sean Dague 

On 03/24/2014 02:05 PM, James E. Blair wrote:
Russell Bryant writes:

On 03/24/2014 12:34 PM, James E. Blair wrote:

So recently we started this experiment with the compute and qa programs
to try using Gerrit to review blueprints.  Launchpad is deficient in
this area, and while we hope Storyboard will deal with it much better,
but it's not ready yet.

This seems to be a point of confusion.  My view is that Storyboard isn't
intended to implement what gerrit provides.  Given that, it seems like
we'd still be using this whether the tracker is launchpad or storyboard.

I don't think it's intended to implement what Gerrit provides, however,
I'm not sure what Gerrit provides is _exactly_ what's needed here.  I do
agree that Gerrit is a much better tool than launchpad for collaborating
on some kinds of blueprints.

Agreed, but the current blueprint system is broken in a way that a half step 
with an imperfect tool is better than keeping the status quo.

However, one of the reasons we're creating StoryBoard is so that we have
a tool that is compatible with our workflow and meets our requirements.
It's not just about tracking work items, it should be a tool for
creating, evaluating, and progressing changes to projects (stories),
across all stages.

I don't envision the end-state for storyboard to be that we end up
copying data back and forth between it and Gerrit.  Since we're
designing a system from scratch, we might as well design it to do what
we want.

One of our early decisions was to say that UX and code stories have
equally important use cases in StoryBoard.  Collaboration around UX
style blueprints (especially those with graphical mock-ups) sets a
fairly high bar for the kind of interaction we will support.

Gerrit is a great tool for reviewing code and other text media.  But
somehow it is even worse than launchpad for collaborating when visual
media are involved.  Quite a number of blueprints could benefit from
better support for that (not just UI mockups but network diagrams, etc).
We can learn a lot from the experiment of using Gerrit for blueprint
review, and I think it's going to help make StoryBoard a lot better for
all of our use cases.

Diagram handling was one of the first questions I asked Russell when I saw the 
repo creation proposal.  Diagrams are very helpful and while gerrit is not 
ideal for handling diagrams, Sphinx should allow us to incorporate them in 
basic way for now.  I view this as an improvement over the 5 different formats 
blueprints are submitted in now.

I think that's fine if long term this whole thing is optimized. I just
do very much worry that StoryBoard keeps going under progressive scope
creep before we've managed to ship the base case. That's a dangerous
situation to be in, as it means it's evolving without a feedback loop.

I'd much rather see Storyboard get us off launchpad ASAP across all the
projects, and then work on solving the things launchpad doesn't do.

+1000 I don’t want to see Storyboard changing scope to the point where it 
doesn’t adequately deliver because it is trying to solve too many problems in 
the first iteration.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Globally-unique VM MAC address to do vendor-backed DHCP

2014-03-18 Thread Mark McClain

On Mar 18, 2014, at 7:40 AM, Roman Verchikov wrote:

Hi stakers,

We’re trying to replace dnsmasq-supplied DHCP for tenant VMs with a vendor’s 
baremetal DHCP server. In order to pass DHCP request to a vendor’s server and 
send DHCP response back to VM we decided to add another OVS bridge (we called 
it br-dhcp), connected to integration bridge (br-int), which will have OVS 
rules connecting VM’s MAC address with br-dhcp port. In this scenario DHCP 
response will only find it’s way back to a VM if VM has globally-unique MAC 

My questions are:

  *   is having code which generates globally-unique MACs for VMs acceptable by 
the community at all?

This question tends to pop up from time to time and there are valid deployment 
and usage scenarios where you would want to assign the same MAC to multiple 

  *   is there a better solution to the problem (we also tried using dnsmasq as 
a DHCP relay there)?

That answer really depends on a number of factors.
 - Are the IP allocations being handled inside or outside of Neutron?
 - Do you allow different networks to have overlapping IP ranges?

If it is outside of the OpenStack deployment then your code can use flow mods 
with you br-dhcp. If Neutron is managing the allocations or you allow 
overlapping IPs, you probably want to consider implementing a driver for the 
DHCP server.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

2014-03-13 Thread Mark McClain

On Mar 13, 2014, at 4:22 PM, Jay Pipes wrote:

 I personally would not be able to attend a mini-summit days before the
 regular summit. I would, however, support a mini-summit about a month
 after the regular summit, where the focus would be on implementing the
 designs that are discussed at the regular summit.

I’ve been working some of the others on the core team to setup another Neutron 
mid-cycle meet up. Like the last one, this will be focused on writing/reviewing 
code for important Juno blueprints (so those who can’t travel can still 
participate).  The trouble with finding dates in late May to early July dates 
is there are a number of large regional OpenStack events, other conferences, 
and the World Cup (we do have a several football fans on the team).  I hope 
that we’ll be able to share the information with everyone soon.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron][rootwrap] Performance considerations, sudo?

2014-03-07 Thread Mark McClain

On Mar 6, 2014, at 3:31 AM, Miguel Angel Ajo wrote:

 Yes, one option could be to coalesce all calls that go into
 a namespace into a shell script and run this in the
 ootwrap  ip netns exec
 But we might find a mechanism to determine if some of the steps failed, and 
 what was the result / output, something like failing line + result code. I'm 
 not sure if we rely on stdout/stderr results at any time.

This is exactly one of the items Carl Baldwin has been investigating.  Have you 
checked out his early work? [1]



OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

2014-03-06 Thread Mark McClain

On Mar 6, 2014, at 4:31 PM, Jay Pipes wrote:

 On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote:
 I think if we can have it before the Juno summit, we can take
 concrete, well thought-out proposals to the community at the summit.
 Unless something has changed starting at the Hong Kong design summit
 (which unfortunately I was not able to attend), the design summits have
 always been a place to gather to *discuss* and *debate* proposed
 blueprints and design specs. It has never been about a gathering to
 rubber-stamp proposals that have already been hashed out in private
 somewhere else.

You are correct that is the goal of the design summit.  While I do think it is 
wise to discuss the next steps with LBaaS at this point in time, I am not a 
proponent of in person mini-design summits.  Many contributors to LBaaS are 
distributed all over the global, and scheduling a mini summit with short notice 
will exclude valuable contributors to the team.  I’d prefer to see an open 
process with discussions on the mailing list and specially scheduled IRC 
meetings to discuss the ideas.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Significance of subnet_id for LBaaS Pool

2014-02-25 Thread Mark McClain

On Feb 25, 2014, at 1:06 AM, Rabi Mishra wrote:

 Hi All,
 'subnet_id' attribute of LBaaS Pool resource has been documented as The 
 network that pool members belong to
 However, with 'HAProxy' driver, it allows to add members belonging to 
 different subnets/networks to a lbaas Pool.  

The documentation is a bit misleading here.  The subnet_id in the pool is used 
to create the port that the load balancer instance uses to connect with the 


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][LBaaS] Object Model discussion

2014-02-24 Thread Mark McClain

On Feb 21, 2014, at 1:29 PM, Jay Pipes wrote:

I disagree on this point. I believe that the more implementation details
bleed into the API, the harder the API is to evolve and improve, and the
less flexible the API becomes.

I'd personally love to see the next version of the LBaaS API be a
complete breakaway from any implementation specifics and refocus itself
to be a control plane API that is written from the perspective of the
*user* of a load balancing service, not the perspective of developers of
load balancer products.

I agree with Jay.  We the API needs to be user centric and free of 
implementation details.  One of my concerns I’ve voiced in some of the IRC 
discussions is that too many implementation details are exposed to the user.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

2014-02-20 Thread Mark McClain
 I’d like to welcome Oleg as member of the core Neutron team as he has received 
more than enough +1s and no negative votes from the other cores. 


On Feb 10, 2014, at 6:28 PM, Mark McClain wrote:

 I’d like to nominate Oleg Bondarev to become a Neutron core reviewer.  Oleg 
 has been valuable contributor to Neutron by actively reviewing, working on 
 bugs, and contributing code.
 Neutron cores please reply back with +1/0/-1 votes.
 OpenStack-dev mailing list

OpenStack-dev mailing list

[openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

2014-02-10 Thread Mark McClain

I’d like to nominate Oleg Bondarev to become a Neutron core reviewer.  Oleg has 
been valuable contributor to Neutron by actively reviewing, working on bugs, 
and contributing code.

Neutron cores please reply back with +1/0/-1 votes.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][QA] Making tests symmetric again

2014-02-07 Thread Mark McClain

On Feb 7, 2014, at 10:16 AM, Matthew Treinish wrote:

So the flag to make tenant isolation was always a temporary thing just for
neutron so we could work out stabilizing things. It's been on by default for
all the other jobs for as long as I can remember. If you think that we've
reached the point were we can greenlight it everywhere, I'll push out the infra
changes to do that.

+1000 to enabling isolation everywhere

- do not executed anymore non-isolated jobs for neutron. I think this was
always the plan anyway.

Yeah, that makes sense, but I still think we should keep 4 tempest jobs running
for the neutron queue. Do you have any ideas for other configs or should we just
duplicate the existing 2? (postgres and mysql)

For now we could run the existing 2 with and without config drive enabled.  
Once the upstream kernel bug is addressed, we should have one config that 
enables key injection with Neutron.


OpenStack-dev mailing list

Re: [openstack-dev] [Governance] Integrated projects and new requirements

2014-02-07 Thread Mark McClain

On Feb 7, 2014, at 4:17 PM, Russell Bryant wrote:

On 02/06/2014 08:47 AM, Thierry Carrez wrote:
Dina Belova wrote:
   Perhaps we should start putting each project on the TC agenda for a
   review of its current standing.  For any gaps, I think we should set a
   specific timeframe for when we expect these gaps to be filled.

Really good idea. New requirements are great, but frankly speaking not
all currently integrated projects fit all of them.
Will be nice to find out all gaps there and fix them asap.

Agreed. I propose we do this in future TC meetings, time permitting. I
propose we start with projects where the PTL was also elected to the TC,
so that we give this new review's process some mileage.

So.. Nova, Cinder, Neutron ?

Sounds good to me.  How about we do them in the order you specified.

I'll go ahead and put together a wiki page that discusses the state of
Nova against the requirements to help the review along.  John and Mark,
do you think you could do the same for Cinder/Neutron at some point in
the next couple weeks?

Yep. I have some time to put together a wiki page for this.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Adding package to requirements.txt

2014-02-03 Thread Mark McClain
I’m interested to know why you are using urllib3 directly.  Have you considered 
using the requests module?  requests is built upon urllib3 and already a 
dependency of Neutron.


On Feb 3, 2014, at 6:45 PM, Hemanth Ravi wrote:

 We are in the process of submitting a third party Neutron plugin that uses 
 urllib3 for the connection pooling feature available in urllib3. httplib2 
 doesn't provide this capability.
 Is it possible to add urllib3 to requirements.txt? If this is OK, please 
 advise on the process to add this.
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][Testr] Brand new checkout of Neutron... getting insane unit test run results

2014-01-13 Thread Mark McClain
I’d rather us explicitly skip the tests if the module is not available.


On Jan 13, 2014, at 3:39 PM, Collins, Sean 

 On Wed, Jan 01, 2014 at 07:56:22PM -0800, Clark Boylan wrote:
 It looks like the problem is that there is a dependency on pyudev
 which only works properly on Linux. The neutron setup_hook does
 properly install pyudev on Linux (explains why the tests run in the
 gate), but would not work properly on windows or OS X. I assume folks
 are trying to run the tests on not Linux? Neutron may want to do
 something similar to what Nova does when libvirt is not importable,
 and use a fake in order to get the tests to run properly anyways.
 Thanks for pointing this out - I've begun work on doing this, and that
 link was very helpful for figuring out what would need to be done.
 Sean M. Collins
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][IPv6] Subnet mode - API extension or change to core API?

2014-01-13 Thread Mark McClain

On Jan 13, 2014, at 12:24 PM, Collins, Sean 

 I posted a message to the mailing list[1] when I first began work on the
 subnet mode keyword, asking if anyone had a suggestion about if it
 should be an API extension or can be a change to the core API.

 I don't know if adding the dhcp_mode attribute to Subnets should be
 considered an API extension (and the code should be converted to an API
 extension) or if we're simply specifying behavior that was originally 

It should be part of the core API and has been planned that way for some time 
(This was agreed on when we first brought this up in Grizzly)  We need to 
ensure that the new mode attribute provides the correct backwards compatible 
behavior with the enable_dhcp boolean.  Ideally in the database model, should 
only store the new value, but the API should accept the enable_dhcp boolean 
until we fully deprecate the API.

OpenStack-dev mailing list

Re: [openstack-dev] [all] Organizing a Gate Blocking Bug Fix Day

2014-01-09 Thread Mark McClain

On Jan 9, 2014, at 7:46 AM, Sean Dague wrote:

 I think we are all agreed that the current state of Gate Resets isn't good. 
 Unfortunately some basic functionality is really not working reliably, like 
 being able to boot a guest to a point where you can ssh into it.
 These are common bugs, but they aren't easy ones. We've had a few folks 
 digging deep on these, but we, as a community, are not keeping up with them.
 So I'd like to propose Gate Blocking Bug Fix day, to be Monday Jan 20th. On 
 that day I'd ask all core reviewers (and anyone else) on all projects to set 
 aside that day to *only* work on gate blocking bugs. We'd like to quiet the 
 queues to not include any other changes that day so that only fixes related 
 to gate blocking bugs would be in the system.
 This will have multiple goals:
 #1 - fix some of the top issues
 #2 - ensure we classify (ER fingerprint) and register everything we're seeing 
 in the gate fails
 #3 - ensure all gate bugs are triaged appropriately
 I'm hopefully that if we can get everyone looking at this one a single day, 
 we can start to dislodge the log jam that exists.
 Specifically I'd like to get commitments from as many PTLs as possible that 
 they'll both directly participate in the day, as well as encourage the rest 
 of their project to do the same.

I’m in.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

2013-12-20 Thread Mark McClain

I’m a bit concerned about Fawad joining the sprint.  He’s a new contributor who 
has never landed a patch in Neutron or Tempest.  Closing the testing gaps with 
experienced devs is the goal of the Montreal sprint and I do not think we’ll 
have manpower to onboard new contributors (3 days is a really short time).  
While I’m happy to welcome more workers there, I do not want to waste his time 
or PLUMgrid’s resources.


On Dec 19, 2013, at 7:02 PM, Edgar Magana wrote:

 Fawad and Myself will be also attending.
 BTW. Fawad will require an invitation letter for visa. He will email you 
 directly with that request.
 On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno wrote:
 Okay time for a recap.
 What: Neutron Tempest code sprint
 Where: Montreal, QC, Canada
 When: January 15, 16, 17 2014
 Location: I am about to sign the contract for Salle du Parc at 3625 Parc
 avenue, a room in a residence of McGill University.
 Time: 9am - 5am
 I am expecting to see the following people in Montreal in January:
 Mark McClain
 Salvatore Orlando
 Sean Dague
 Matt Trenish
 Jay Pipes
 Sukhdev Kapur
 Miguel Lavelle
 Oleg Bondarev
 Rossella Sblendido
 Emilien Macchi
 Sylvain Afchain
 Nicolas Planel
 Kyle Mestery
 Dane Leblanc
 Sumit Naiksatam
 Henry Gessau
 Don Kehn
 Carl Baldwin
 Justin Hammond
 Anita Kuno
 If you are on the above list and can't attend, please email me so I have
 an up-to-date list. If you are planning on attending and I don't have
 your name listed, please email me without delay so that I can add you
 and you get done what you need to get done to attend.
 I have the contract for the room and will be signing it and sending it
 in with the room deposit tomorrow. Monty has about 6 more hours to get
 back to me on this, then I just have to go ahead and do it.
 Caterer is booked and I will be doing menu selection over the holidays.
 I can post the intended, _the intended_ menu once I have decided. Soup,
 salad, sandwich - not glamourous but hopefully filling. If the menu on
 the day isn't the same as what I post, please forgive me. Unforeseen
 circumstances may crop up and I will do my best to get you fed. One
 person has identified they have a specific food request, if there are
 any more out there, please email me now. This covers breakfast, lunch
 and tea/coffee all day.
 Henry Gessau will be social convener for dinners. If you have some
 restaurant suggestions, please contact Henry. Organization of dinners
 will take place once we congregate in our meeting room.
 T-shirts: we decided that the code quality of Neutron was a higher
 priority than t-shirts.
 One person required a letter of invitation for visa purposes and
 received it. I hope the visa has been granted.
 Individuals arrangements for hotels seem to be going well from what I
 have been hearing. A few people will be staying at Le Nouvel Hotel,
 thanks for finding that one, Rosella.
 Weather: well you got me on this one. This winter is colder than we have
 had in some time and more snow too. So it will be beautiful but bring or
 buy warm clothes. A few suggestions:
 * layer your clothes (t-shirt, turtleneck, sweatshirt)
 * boots with removable liners (this is my boot of choice: remove the liners at the end of each day to dry them
 * warm coat
 * toque (wool unless you are allergic) I'm seeing them for $35, don't
 pay that much, you should be able to get something warm for $15 or less
 * warm socks (cotton socks and wool over top)- keep your feet dry
 * mitts (mitts keep my fingers warmer than gloves)
 * scarf
 If the weather is making you panic, talk to me and I will see about
 bringing some of my extra accessories with me. The style might not be
 you but you will be warm.
 Remember, don't lick the flagpole. It doesn't matter what your friends
 tell you.
 That's all I can think of, if I missed something, email me.
 Oh, and best to consider me offline from Jan.2 until the code sprint.
 Make sure you have all the information you need prior to that time.
 See you in Montreal,
 On 11/19/2013 11:31 AM, Rossella Sblendido wrote:
  Hi all,
  sorry if this is a bit OT now.
  I contacted some hotels to see if we could get a special price if we book
  many rooms. According to my research the difference in price is not much.
  Also, as Anita was saying, booking for everybody is more complicated.
  So I decided to booked a room for myself.
  I share the name of the hotel, in case you want to stay in the same place
  It's close to the meeting room and the price is one

Re: [openstack-dev] [Neutron] Find the compute host on which a VM runs

2013-11-15 Thread Mark McClain

Your workflow is very similar to many other plugins.  You’ll want to look at 
implementing the port binding extension in your plugin.  The port binding 
extension allows Nova to inform Neutron of the host where the VM is running.  


On Nov 15, 2013, at 9:55 AM, Stefan Apostoaie wrote:

 I'm creating a Neutron/Quantum plugin to work with a networking controller 
 that takes care of the configuration of the virtual networks. Basically what 
 we are doing is receive the API calls and forward them to our controller to 
 run the required configuration on the compute hosts. 
 What I need to know when a create_port call is made to my plugin is on which 
 compute host the VM is created (so that our controller will run the 
 configuration on that host). Is there a way to find out this information from 
 the plugin?
 Stefan Apostoaie
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] New plug-ins requirements

2013-11-15 Thread Mark McClain

On Nov 14, 2013, at 2:02 AM, Edgar Magana wrote:
 I do agree with you. When I said in my first email little bit of guidance I 
 mean the policy for Icehouse and moving forward. I do not want to make our 
 PTL angry  :-)

I wouldn’t worry about making me angry.  I officiated football (soccer) for 
many years.  It takes a lot to make me angry :)

 I hope you can commend on this thread, otherwise I will bring this topic on 
 our next IRC meeting.

I’ve posted the policy in a separate thread.  If there are any questions, feel 
free to ask in that thread and we’ll be able to  clarify and additional details 
to the wiki version so that they documented for everyone in the community. This 
already a planned agenda item for Monday’s team meeting too.


OpenStack-dev mailing list

Re: [openstack-dev] [neutron] [ipv6] IPv6 meeting - Thursdays 21:00UTC - #openstack-meeting-alt

2013-11-14 Thread Mark McClain

On Nov 13, 2013, at 12:46 PM, Collins, Sean (Contractor) wrote:

 On Wed, Nov 13, 2013 at 10:20:55AM -0500, Shixiong Shang wrote:
 Thanks a bunch for finalizing the time! Sorry for my ignorance….how do we 
 usually run the meeting? On Webex or IRC channel? 
 I'm not opposed to Webex (other teams have used it before) - but it
 would involve more set-up. We'd need to publish recordings,
 so that there is a way for those that couldn't attend to review,
 similar to how the IRC meetings are logged.

Please use IRC.  It’s the community standard meeting platform and provides 
instantly searchable text logs.

OpenStack-dev mailing list

[openstack-dev] [Neutron] Plugin and Driver Inclusion Requirements

2013-11-14 Thread Mark McClain
The Neutron team has experienced tremendous growth in vendor plugins and 
drivers over the last few cycles.  As a result of the growth, the Neutron team 
is implementing new requirements for plugin and driver code for Icehouse cycle 
to ensure continued code quality and stability.

- Each third party plugin/driver shall designate a point of contact for the 
coordinated release cycle.
- To be designated as compatible, a third-party plugin and/or driver code must 
implement external third party integration testing.
- Policy is in effect immediately for new plugin/drivers.
- Existing plugin/drivers have until Icehouse-2 to become compliant.

Ensuring release quality through proper testing is an important tenant of the 
OpenStack community and Neutron team wants to do our part. We are introducing 
changes below provide more visibility into the quality and stability of vendor 
plugin and driver code.  The policies described here are in effect immediately.


Code proposals for third party plugins have always presented a review challenge 
for the Neutron core team.  In the early days, code was often proposed by core 
project contributors and our review process only validated whether the 
requirements were met for community coding style and unit testing.  As Neutron 
has added new resources via extensions, it has become more difficult for 
Neutron reviewers to ensure the proposed code is functional.  Many of the 
plugins and/or drivers require proprietary hardware and/or software to conduct 
such testing.

In addition to testing changes, the Neutron team is revising the requirements 
for the point of contact for third party code.  The changes bring the written 
expectations for contacts in line with current practice.

Point of Contact Requirements
Each third party plugin and/or driver shall designate a point of contact for 
each coordinated release cycle.  The contact will serve as a liaison between 
the Neutron core team and the vendor or community supporting the plugin or 
driver.  The contact shall:
- Attend weekly Neutron team IRC meetings
- Be an active reviewer and contributor 
- Be an active participant on openstack-dev mailing list
- Assist the core team with triaging bugs specific to the plugin and/or 
- Ensure OpenStack development deadlines are properly communicated back 
to their company and/or community

NOTE: The this information can be maintained here:

Testing Requirements
To be designated as compatible, a third-party plugin and/or driver code must 
implement external third party testing.  The testing should be Tempest executed 
against a Devstack build with the proposed code changes.  The environment 
managed by the vendor should be configured to incorporate the plugin and/or 
driver solution.  The OpenStack Infrastructure team has provided details on how 
to integrate 3rd party testing at:

and Tempest can be found at:

The Neutron team expects that the third party testing will provide a +/-1 
verify vote for all changes to a plugin or driver’s code.  In addition, the 
Neutron team expects that the third party test will also vote on all code 
submissions by the jenkins user.  The jenkins user regularly submits 
requirements changes and the Neutron team hopes to catch any possible 
regressions as early as possible.

Existing Plugin and Drivers
Plugins and drivers currently in the Neutron project repository will be given a 
grace period until the Icehouse-2 milestone to implement external third party 
testing.  At that time, the Neutron team will release a list of the compatible 
plugins and drivers (i.e. those that meet the testing requirements).  Plugins 
and drivers that do not have external testing will be deprecated at the 
Icehouse release and will be candidates for removal when the J-release cycle 

OpenStack-dev mailing list

Re: [openstack-dev] [nova] Blueprint for Juniper OpenContrail vrouter nova vif driver support

2013-11-13 Thread Mark McClain

On Nov 12, 2013, at 10:06 PM, Kyle Mestery (kmestery) 
 We have seen the BP and review. The problem that we Neutron core are currently
 looking at is something which was discussed at the Summit in Hong Kong last 
 The requirement of having Smokestack/Tempest tests for plugins. As a core 
 team, we
 haven't decided yet if new plugins will require these tests before being 
 added to the

I’ll send out more information later today, but all new Neutron plugin and 
drivers proposed for inclusion in Icehouse will require testing to be in place 
prior to acceptance into the tree.  Without the proper testing infrastructure 
in place there is  no way for the review team to know if the submitted code 


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] IPv6 sub-team?

2013-11-06 Thread Mark McClain
I definitely think this should be a standing Neutron sub team. 


 On Nov 6, 2013, at 7:50 AM, Collins, Sean (Contractor) wrote:
 Is there any interest in organizing a IPv6 sub-team, similar to how
 there are sub-teams for FwaaS, VPNaas, ML2, etc?
 Sean M. Collins
 AIM: seanwdp
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] Need suggestions and pointers to start contributing for development :

2013-10-11 Thread Mark McClain

On Oct 11, 2013, at 9:14 AM, Dolph Mathews wrote:
 On Friday, October 11, 2013, Mayank Mittal wrote:
 Hi Teams,
 Please suggest and guide for starting to contribute in development. About me 
 - I have been working on L2/L3 protocol, SNMP, NMS development and ready to 
 contribute as a full timer to openstack. 
 PS : My interest lies in LB and MPLS. Any pointers to respective teams will 
 help a lot.
 Welcome! It sounds like you'd be interested in contributing to neutron:
 This should get you pointed in the right direction:


Dolph is correct that Neutron matches up with your interests.  Here's bit more 
specific information on Neutron development:

OpenStack-dev mailing list

[openstack-dev] [Neutron] PTL Candidacy

2013-09-20 Thread Mark McClain


I writing to announce my candidacy for the OpenStack Networking (Neutron) PTL.

I am the current Neutron PTL.  Our team continued to grow during the Havana 
cycle and both existing and new contributors worked to deliver double the 
number of blueprints than the previous release.  Our vibrant ecosystem makes me 
excited for the future of Neutron and I would love to continue as the PTL.


I am a Neutron core developer with 13 years of commercial Python development 
experience.  During my career, I have developed and deployed network 
applications based on the same underlying libraries used throughout Neutron.  I 
started contributing to Neutron project during the Essex development cycle.  In 
Folsom, I was promoted to core and was the primary developer of the DHCP 
implementation and Neutron's network namespace library.  During Grizzly, I 
worked on the metadata service, database migrations, and LBaaS reference 

Havana Accomplishments

During the Havana cycle, I worked as a developer, core team member, and a 
technical lead.

- Planned and implemented the Quantum to Neutron name change.
- Most active reviewer on the Neutron team 
- Organized the Networking track at the Havana Design Summit.
- Led bug triaging and sub-team assignment.
- Interfaced with vendors new to Neutron and helped in the integration of their 
- Assisted members of the community to further their understanding of Neutron 
and improve Python development best practices.
- Promoted Neutron by delivering presentations at conferences and regional meet 
ups worldwide.


During the Icehouse development cycle, I'd like to see the team focus on:

- Continuing to grow the community of contributors and code reviewers.
- Improving documentation for both deployers and developers.
- Build upon the services added in Havana to extend and improve load balancing, 
firewalling, and VPN.
- Integrating plugins from vendors new to the community including FWaaS, LBaaS, 
ML2, VPNaaS plugins/drivers.
- More efficient Neutron system testing and gating including full Tempest 
- Further work to ease deploying at scale.
- Refactoring the API layer to leverage a common WSGI framework as other 
OpenStack projects.
- Improving database resource modeling and extension management.
- Unified network service management framework. 
- Continued support of the Horizon team to assist with Neutron integration.
- Defined migration path from nova-network to Quantum.

I'd love the opportunity to continue as the PTL and work with the Neutron team 
to fill in the gaps during the design summit in Hong Kong.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Need some clarity on security group protocol numbers vs names

2013-09-12 Thread Mark McClain
Names are not necessarily portable across implementations and this would be a 
major change to make this late in the cycle.  At this point in the cycle, we 
need to focus on ensuring fixes minimize disruption.


On Sep 11, 2013, at 6:03 PM, Arvind Somya (asomya) wrote:

 Ok, those were some good points. I personally like the approach of letting
 each implementation specify it's own set of supported protocols.
 I'll change my patch to simply convert all protocols to names (more
 On 9/11/13 3:06 PM, Justin Hammond wrote:
 I agree with you. Plugin was a mere example and it does make sense to
 allow the provider to define custom protocols.
 On 9/11/13 12:46 PM, Akihiro Motoki wrote:
 Hi Justin,
 My point is what
 On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond wrote:
 As it seems the review is no longer the place for this discussion, I
 copy/paste my inline comments here:
 I dislike the idea of passing magical numbers around to define
 (defined or otherwise). I believe there should be a common set of
 protocols with their numbers mapped (such as this constants business)
 a well defined way to validate/list said common constants.
 I agree that value should be validated appropriately in general.
 A configurable list of allowed protocols looks good to me.
 wishes to add support for a protocol outside of the common case, it
 be added to the list in a pluggable manner.
 Ex: common defines the constants 1, 6, 17 to be valid but
 wants to support 42. It should be my plugin's responsibility to add 42
 the list of valid protocols by appending to the list given a pluggable
 interface to do so. I do not believe plugins should continue to update
 common.constants file with new protocols, but I do believe explicitly
 stating which protocols are valid is better than allowing users to
 possibly submit protocols erroneously.
 I think this is just a case a backend plugin defines allowed protocols.
 I also see a different case: a cloud provider defines allowed protocols.
 For example VLAN network type of OVS plugin can convey any type of
 including GRE, STCP and so on if a provider wants to do so.
 We need to allow a provider to configure the list.
 Considering the above, what we need to do looks:
 (a) to validate values properly,
 (b) to allow a plugin to define what protocols should be allowed
   (I think we need two types of lists: possible protocols and
 default allowed protocols)
 (c) to allow a cloud provider (deployer) to customize allow protocols.
   (Of course (c) is a subnet of possible protocols in (b))
 Does it make sense?
 The above is just a start point of the discussion and some list can be
 # Whether (c) is needed or not depends on the default list of (b).
 # If it is wide enough (c) is not needed. The current list of (b) is
 [tcp, udp, icmp]
 # and it looks too small set to me, so it is better to have (c) too.
 If the plugins use a system such as this, it is possible that new,
 protocols can be found to be core. See NETWORK_TYPE constants.
 I think the situation is a bit different. What network types are
 allowed is tightly
 coupled with a plugin implementation, and a cloud provider choose a
 based on their needs. Thus the mechanism of NETWORK_TYPE constants
 make sense to me too.
 tl;dr: magic constants are no good, but values should be validated in a
 pluggable and explicit manner.
 As I said above, I agree it is important to validate values properly in
 On 9/11/13 10:40 AM, Akihiro Motoki wrote:
 Hi all,
 Arvind, thank you for initiate the discussion about the ip protocol in
 security group rules.
 I think the discussion point can be broken down into:
 (a) how to specify ip protocol : by name, number, or both
 (b) what ip protocols can be specified: known protocols only, all
 protocols (or some subset of protocols including unknown protocols)
where known protocols is defined as a list in Neutron (a list
 of constants or a configurable list)
 (b) is the main topic Arvind and I discussed in the review.
 If only known protocols are allowed, we cannot allow protocols which
 are not listed in the known protocol list.
 For instance, if tcp, udp and icmp are registered as known
 protocols (this is the current neutron implementation),
 a tenant cannot allow stcp or gre.
 Pros of known protocols only is the infrastructure provider can
 control which protocols are allowed.
 Cons is that users cannot use ip protocols not listed in a known list
 and a provider needs to maintain a known protocol list.
 Pros and cons of all protocols allowed is vice versa.
 If a list of known protocols is configurable, we can cover both cases,
 e.g., an empty list or a list [ANY] means all 

Re: [openstack-dev] [Neutron] Need some clarity on security group protocol numbers vs names

2013-09-11 Thread Mark McClain

On Sep 11, 2013, at 1:46 PM, Akihiro Motoki wrote:
 On Thu, Sep 12, 2013 at 12:46 AM, Justin Hammond wrote:
 As it seems the review is no longer the place for this discussion, I will
 copy/paste my inline comments here:
 I dislike the idea of passing magical numbers around to define protocols
 (defined or otherwise). I believe there should be a common set of
 protocols with their numbers mapped (such as this constants business) and
 a well defined way to validate/list said common constants.
 I agree that value should be validated appropriately in general.
 A configurable list of allowed protocols looks good to me.

I'm -2.  The original bug has morphed into a mini-feature and is not allowable 
under our feature freeze rules.

There are many valid reasons for allowing 41, 47, etc to a guest and we should 
continue to allow 0=proto_num=255 in Havana.  We should also refocus on the 
original bug intent and normalize the data to prevent duplicate rules in the 
common cases (tcp, udp, icmp, icmp, icmpv6).

Any other changes should be open for discussion in Icehouse as we'll need to 
consider the deployment and backwards compatibility issues.  Feel free to 
proposal a session on this for the Hong Kong summit.


OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] New Plug-in development for Neutron

2013-09-10 Thread Mark McClain
I think Gary and Kyle have answered this very well; however I do have a few 
things to add.  It is definitely too late for Havana, so Icehouse is next 
available release for new plugins.  I can work with you offline to find you a 
core sponsor.

On Sep 10, 2013, at 9:37 AM, Kyle Mestery (kmestery) 

 On Sep 10, 2013, at 4:05 AM, P Balaji-B37839 wrote:
 We have gone through the below link for new plug-in development.
 Just want to confirm that is it mandatory to be Core Neutron Developer for 
 submitting a new plug-in.?
 It's not necessary for you to have a core developer from your company, but 
 you will need an existing core developer to support your plugin upstream. 
 When you file the blueprint, let us know and we'll work with you on this one 
 How do we get a reviewer for this like Can we approach any Core Neutron 
 developer for review our plugin?
 We are developing new plug-in for our product and want to make it upstream 
 to Neutron Core.
 Any information on this will be helpful!.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Bug #1209011

2013-09-09 Thread Mark McClain

Thanks for pointing this out.  I've fixed the bug status.


On Sep 9, 2013, at 6:33 PM, Baldwin, Carl (HPCS Neutron) wrote:

 Hi all,
 This bug was marked as fix released for H-3.  However, the fix that was
 merged was reverted due to gate breakage.  The patch was resubmitted as and fixes the gate breakage but
 this new patch has not been merged.  So, the bug state of Yix released
 is not accurate.
 This bug needs one of the following two actions:
 1) The new patch accepted and bug state changed to Fix Committed.
 1) Bug state reverted to In Progress.
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Resource URL support for more than two levels

2013-08-29 Thread Mark McClain
Stay tuned.  There are folks working on a proposed set of API framework 
changes.  This will be something that we'll discuss as part of deciding the 
features in the Icehouse release.


On Aug 29, 2013, at 10:08 AM, Justin Hammond 

 I find that kind of flexibility quite valuable for plugin developers. +1 to 
 this. I'd like to be involved if possible with helping you with it.
 From: balaji patnala
 Reply-To: OpenStack Development Mailing List
 Date: Thu, 29 Aug 2013 11:02:33 +0530
 To: OpenStack Development Mailing List
 Subject: Re: [openstack-dev] [Neutron] Resource URL support for more than two 
 When compared to Nova URL implementations, It is observed that the Neutron 
 URL support cannot be used for more than TWO levels.
 Applications which want to add as PLUG-IN may be restricted with this.
 We want to add support for changes required for supporting more than TWO 
 Levels of URL by adding the support changes required in Core Neutron Files.
 Any comments/interest in this.?
 On Tue, Aug 27, 2013 at 5:04 PM, B Veera-B37207 wrote:
 The current infrastructure provided in Quantum [Grizzly], while building 
 Quantum API resource URL using the base function ‘base.create_resource()’ and 
 GET  /lb/pools/pool_id/members/member_id
 Some applications may need more than two levels of URL support. Example: GET  
 If anybody is interested in this, we want to contribute for this as BP and 
 make it upstream.
 OpenStack-dev mailing list
 ___ OpenStack-dev mailing list
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron][Climate] bp:configurable-ip-allocation

2013-08-22 Thread Mark McClain

Expect to updated code posted soon for Havana.


On Aug 22, 2013, at 12:47 AM, Nikolay Starodubtsev 

 Hi, everyone!
 We are working on Climate, and we are interested in I 
 see two changes connected with this bp, but they both were abandoned in the 
 beginning of the year. Can anyone give me an answer about implementation 
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] proposing Alex Gaynor for core on openstack/requirements

2013-08-16 Thread Mark McClain


On Aug 16, 2013, at 11:04 AM, Doug Hellmann wrote:

 I'd like to propose Alex Gaynor for core status on the requirements project.
 Alex is a core Python and PyPy developer, has strong ties throughout the 
 wider Python community, and has been watching and reviewing requirements 
 changes for a little while now. I think it would be extremely helpful to have 
 him on the team.
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] Usage of mox through out the Openstack project.

2013-07-25 Thread Mark McClain

On Jul 25, 2013, at 4:01 AM, Julien Danjou wrote:

 On Wed, Jul 24 2013, Russell Bryant wrote:
 A practical approach would probably be:
 1) Prefer mock for new tests.
 2) Use suggestion #2 above to mitigate the Python 3 concern.
 3) Convert tests to mock over time, opportunistically, as tests are
 being updated anyway.  (Or if someone *really* wants to take this on as
 a project ...)
 Agreed. I will -1 every new patch coming with mox inside. :-)
 And I'll probably do some conversion for Oslo anyway.

The Neutron project has been enforcing this approach for about a year now.  
We're down to 8 files that still rely on Mox.


OpenStack-dev mailing list

[openstack-dev] [Neutron] Proposal to add new neutron-core members

2013-07-23 Thread Mark McClain

I'd like to propose that Kyle Mestery and Armando Migliaccio be added to the 
Neutron core team.  Both have been very active with valuable reviews and 
contributions to the Neutron community.

Neutron core team members please respond with +1/0/-1.

OpenStack-dev mailing list

Re: [openstack-dev] [Neutron] Service Type Framework implementation

2013-07-09 Thread Mark McClain

On Jul 9, 2013, at 5:37 PM, Nachi Ueno wrote:
 We have two suboption for db api based solution
 Option4. REST API + DB with Preload with Conf
 so IMO, we can drop  option3.
 I believe option4 is easy to implement.

I'm not onboard with option 4 either.  At the last summit, we talked about 
making Neutron easier to deploy.  Using a database to sync configuration state 
adds complexity.  Having some values in a configuration and others in the 
database (even cached) is a recipe for a major headache.  For the deployments 
running multiple instances of Neutron, they should be using Chef, Chef, Salt, 
etc for managing their configs anyway.

Using only configuration files (option 1) remains my preference.

OpenStack-dev mailing list

Re: [openstack-dev] [neutron] Renaming and code reviews...

2013-07-08 Thread Mark McClain
The core team took care of renaming the files over the weekend, so that reviews 
going forward should behave as normal. (i.e. Adds are truly additions and 
modifications are mods).  I looked at the review you referenced and that was 
file was a proposed addition before the name change.  Git/Gerrit as behaving as 
expected for this change.

As for making staged changes, that will run into problems as module paths will 
be out-of-sync and the change could not pass the gate.  Additionally, that 
would make it hard for changes to be applied or reverted atomically.


On Jul 8, 2013, at 3:54 PM, Paul Michali wrote:

 Many people are converting their code, which is out for review, to neutron. 
 One thing I'm seeing is the files which have been moved and renamed, are 
 showing up as new files (not to pick on it, but as an example
  so it is hard to tell if there are other changes going on.
 Should submitters ensure that the change set only has renaming changes (and 
 maybe include a note in the patch set saying so), or is there a way that 
 multiple patch sets can be used to make that clear (like one to rename in the 
 text of the file, and a second one to move the file to a new location)?
 Just wondering if there is a way to make reviewing easier…
 PCM (Paul Michali)
 IRC   pcm_  (
 TW   @pmichali
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-24 Thread Mark McClain
Here's the blueprint…

On Jun 21, 2013, at 5:34 PM, Edgar Magana wrote:

 Can you point me to the BP for this feature?
 I want to keep an eye on it.
 From: Mark McClain
 Reply-To: OpenStack List
 Date: Friday, June 21, 2013 12:41 PM
 To: OpenStack List
 Subject: Re: [openstack-dev] [Networking] Allocation of IPs
 There will be a deployment option where you can configure the default IP 
 allocator.  Additionally, the allocator will be configurable at subnet 
 creation time.
 On Jun 20, 2013, at 4:51 PM, Edgar Magana wrote:
 Could it be possible to add a flag to disable the allocation for the IP?
 If the no allocation flag is enabled, all ports will have an empty value 
 for IPs.
  It will increase the config parameters in quantum, should we try it?
 From: Mark McClain
 Reply-To: OpenStack List
 Date: Thursday, June 20, 2013 1:13 PM
 To: OpenStack List
 Subject: Re: [openstack-dev] [Networking] Allocation of IPs
 There's work under way to make IP allocation pluggable. One of the options 
 will include not having an allocator for a subnet.
 On Jun 20, 2013, at 2:36 PM, Edgar Magana wrote:
 So far in Networking (formerly Quantum) IPs are pre-allocated when a new 
 port is created by the following def:
 _allocate_ips_for_port(self, context, network, port):
 If we are using a real DHCP (not the dnsmasq process) that does not accept 
 static IP allocation because it only allocates IPs based on its own 
 algorithm, how can we tell Networking to not allocate an IP at all?
 I don’t think that is possible based on the code but I would like to know 
 if somebody has gone through the same problem and have a workaround 
 OpenStack-dev mailing list
 ___ OpenStack-dev mailing list 
 OpenStack-dev mailing list
 ___ OpenStack-dev mailing list
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-21 Thread Mark McClain
There will be a deployment option where you can configure the default IP 
allocator.  Additionally, the allocator will be configurable at subnet creation 


On Jun 20, 2013, at 4:51 PM, Edgar Magana wrote:

 Could it be possible to add a flag to disable the allocation for the IP?
 If the no allocation flag is enabled, all ports will have an empty value 
 for IPs.
  It will increase the config parameters in quantum, should we try it?
 From: Mark McClain
 Reply-To: OpenStack List
 Date: Thursday, June 20, 2013 1:13 PM
 To: OpenStack List
 Subject: Re: [openstack-dev] [Networking] Allocation of IPs
 There's work under way to make IP allocation pluggable. One of the options 
 will include not having an allocator for a subnet.
 On Jun 20, 2013, at 2:36 PM, Edgar Magana wrote:
 So far in Networking (formerly Quantum) IPs are pre-allocated when a new 
 port is created by the following def:
 _allocate_ips_for_port(self, context, network, port):
 If we are using a real DHCP (not the dnsmasq process) that does not accept 
 static IP allocation because it only allocates IPs based on its own 
 algorithm, how can we tell Networking to not allocate an IP at all?
 I don’t think that is possible based on the code but I would like to know if 
 somebody has gone through the same problem and have a workaround solution.
 OpenStack-dev mailing list
 ___ OpenStack-dev mailing list
 OpenStack-dev mailing list

OpenStack-dev mailing list

Re: [openstack-dev] [Networking] Allocation of IPs

2013-06-20 Thread Mark McClain
There's work under way to make IP allocation pluggable. One of the options will 
include not having an allocator for a subnet.


On Jun 20, 2013, at 2:36 PM, Edgar Magana wrote:

 So far in Networking (formerly Quantum) IPs are pre-allocated when a new port 
 is created by the following def:
 _allocate_ips_for_port(self, context, network, port):
 If we are using a real DHCP (not the dnsmasq process) that does not accept 
 static IP allocation because it only allocates IPs based on its own 
 algorithm, how can we tell Networking to not allocate an IP at all?
 I don’t think that is possible based on the code but I would like to know if 
 somebody has gone through the same problem and have a workaround solution.
 OpenStack-dev mailing list

OpenStack-dev mailing list