[openstack-dev] [neutron][all] So long, and thanks for all the fish

[John Davidge]

Friends and colleagues,

It is with a heavy heart that I write to say my adventure in the OpenStack
community is coming to an end. It began in 2012 with my first job as an
intern at Cisco, and ends here as the Technical Lead for Neutron in the
OpenStack Innovation Center at Rackspace.

In that time I’ve worked with a great many wonderful people from all
corners of this community, on a variety of projects that I’m proud to
include my name in the commit logs. Thank you all for creating an exciting
place to work, to debate, and occasionally to argue about the incredible
democratizing power that is OpenStack. Your passion and expertise are an
inspiration to the world.

Regretfully, I’m leaving a void in both the Neutron team and the OpenStack
Manuals team. Neutron will need a new Docs liaison, and OpenStack Manuals
will need a new lead for the Networking Guide. The cross-project work
we’ve done together over the last couple of cycles has been engaging and
fulfilling, and I encourage anyone interested in either or both roles to
get in touch with Kevin Benton and Alexandra Settle.

Good luck and best wishes to all of you in the future.

Until we meet again,

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[John Davidge]

+1

On 2/20/17, 4:48 AM, "Carlos Gonçalves"  wrote:

>+1
>
>On Mon, Feb 20, 2017 at 9:17 AM, Kevin Benton
> wrote:
>
>No problem. Keep sending in RSPVs if you haven't already.
>
>On Mon, Feb 20, 2017 at 2:59 AM, Furukawa, Yushiro
> wrote:
>
>
>
>+1
>
>Sorry for late, Kevin!!
>
>
>  Yushiro Furukawa
>
>From: Kevin Benton [mailto:ke...@benton.pub]
>
>
>
>
>Hi all,
>
>
>I'm organizing a Neutron social event for Thursday evening in Atlanta
>somewhere near the venue for dinner/drinks. If you're interested, please
>reply to this email with a "+1" so I can get a general count for a
>reservation.
>
>
>
>Cheers,
>
>Kevin Benton
>
>
>
>
>
>
>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
>



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [docs] PTG Neutron Documentation Session

[John Davidge]

Hi Everyone,

The OpenStack Manuals team will be holding a PTG session to discuss the
current state and future of the Networking Guide[1] on:

Tuesday at 3:00pm - 3:40pm in the documentation room.

Anyone interested in helping with continued improvements and bug fixes is
encouraged to attend.

Thanks,

John

[1] https://docs.openstack.org/networking-guide/



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Davidge]

On 1/9/17, 2:11 PM, "Armando M."  wrote:

>Hi neutrinos,
>
>The PTL nomination week is fast approaching [0], and as you might have
>guessed by the subject of this email, I am not planning to run for Pike.
>If I look back at [1], I would like to think that I was able to exercise
>the influence on the goals I set out
> with my first self-nomination [2].
>
>That said, when it comes to a dynamic project like neutron one can't
>never claim to be *done done* and for this reason, I will continue to be
>part of the neutron core team, and help the future PTL drive the next
>stage of the project's journey.
>
>I must admit, I don't write this email lightly, however I feel that it is
>now the right moment for me to step down, and give someone else the
>opportunity to grow in the amazing role of neutron PTL! I have certainly
>loved every minute of it!
>
>Cheers,
>Armando
>
>[0] https://releases.openstack.org/ocata/schedule.html
>[1]
>https://review.openstack.org/#/q/project:openstack/election+owner:armando-
>migliaccio
>[2] https://review.openstack.org/#/c/223764/
>

We’re all doomed! DOOMED!

But seriously, thank you for all of the work you’ve put into leading
neutron for as long as you have. Your decisiveness on various issues has
allowed development to continue at pace rather than always getting bogged
down in never ending debates.

This blow is softened only by the knowledge that there are some excellent
potential candidates who are ready (and willing?) to step into the role.

Thank you, and I’m looking forward to your continued contributions.

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Davidge]

On 12/21/16, 4:11 PM, "Matt Kassawara"  wrote:

>Howdy!
>
>
>After several years of contributing to OpenStack documentation, a
>significant change in my career path warrants resigning from my role as a
>core reviewer. Working with the OpenStack community was a great
>experience and I hope it continues to grow... with
> sufficient documentation, of course.
>
>
>Cheers,
>Matt
>

Thanks for all of your work on the networking guide, and good luck in your
future endeavors!

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt

[John Davidge]

Huge +1 from me. Miguel has been doing an excellent job chairing the
l3-subteam meetings for a long time now. Well deserved!

On 12/16/16, 11:00 AM, "Rossella Sblendido"  wrote:

>well deserved, +1!
>
>On 12/16/2016 09:32 AM, Miguel Angel Ajo Pelayo wrote:
>> +1 :)
>>
>> On Fri, Dec 16, 2016 at 2:44 AM, Vasudevan, Swaminathan (PNB Roseville)
>> >
>> wrote:
>>
>> +1
>>
>> __ __
>>
>> *From:*Armando M. [mailto:arma...@gmail.com
>>]
>> *Sent:* Thursday, December 15, 2016 3:15 PM
>> *To:* OpenStack Development Mailing List (not for usage questions)
>> > >
>> *Subject:* [openstack-dev] [neutron] proposing Miguel Lavalle as
>> neutron core and Brian Haley as L3 Lt
>>
>> __ __
>>
>> Hi neutrinos,
>>
>> __ __
>>
>> Miguel Lavalle has been driving the project forward consistently and
>> reliably. I would like to propose him to be entrusted with +2/+A
>> rights in the areas he's been most prolific, which are L3 and DHCP.
>>
>>
>> __ __
>>
>> At the same time, I'd like to propose Brian Haley as our next Chief
>> L3 Officer. Both of them have worked with Carl Baldwin extensively
>> and that can only be a guarantee of quality.
>>
>> __ __
>>
>> Cheers,
>>
>> Armando 
>>
>> __ __
>>
>> [1] https://review.openstack.org/#/c/411531/
>> 
>>
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>
>>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>>
>>
>>
>>
>>
>>_
>>_
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] trunk api performance and scale measurments

[John Davidge]

On 12/6/16, 6:06 PM, "Tidwell, Ryan"  wrote:

>
>I failed to make much mention of it in previous write-ups, but I also
>encountered scale issues with listing ports after a certain threshold. I
>haven’t gone back
> to identify where the tipping point is, but I did notice that Horizon
>began to really bog down as I added ports to the system. On the surface
>it didn’t seem to matter whether these ports were used as subports or
>not, the sheer volume of ports added to the
> system seemed to cause both Horizon and more importantly GET on
>v2.0/ports to really bog down.
>
>-Ryan

Could this be related to https://bugs.launchpad.net/neutron/+bug/1611626 ?

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Davidge]

It's been a pleasure to work with you these past few years, Carl. I wish you 
all the best in whatever's next for you. Hopefully we'll meet again soon in the 
not so distant future.

There will forever be a Carl-shaped hole in our codebase.

John

From: Carl Baldwin >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, November 17, 2016 at 6:42 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Stepping down from core

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such that 
I'm not able to keep up with my duties as a Neutron core reviewer, L3 
lieutenant, and drivers team member. My participation has dropped off 
considerably since Newton was released and I think it is fair to step down and 
leave an opening for others to fill. There is no shortage of talent in Neutron 
and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in Openstack and 
Neutron in the future if things change again in that direction. This is a great 
community and I've had a great time participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and will be 
happy to help out where I am able. Feel free to ping me.

Carl


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[John Davidge]

+1

Thanks Miguel!

From: Miguel Lavalle >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Friday, October 14, 2016 at 7:30 PM
To: OpenStack Development Mailing List 
>
Subject: [openstack-dev] [Neutron] Neutron team social event in Barcelona

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30. After 
doing some Google research, I am proposing Raco de la Vila, which is located in 
Poblenou: http://www.racodelavila.com/en/index.htm. The menu is here: 
http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue: 
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people under 
'Neutron' or "Miguel Lavalle". Please confirm your attendance so we can get a 
final count.

Here's some reviews: 
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[John Davidge]

Hi Erin,

Thank you for the details. Can you tell us anything about how discount codes 
for ATCs will change for Boston and onwards?

Thanks,

John

From: Erin Disney >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Thursday, October 13, 2016 at 10:34 PM
To: 
"openstack-dev@lists.openstack.org" 
>
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

Hey everyone- wanted to introduce myself and answer a couple questions from 
this thread. I’m Erin, part of the Foundation’s Marketing/Events team, and I 
have been helping organize the inaugural PTG.

Here is what I can tell you from a logistics perspective:

  *   The first PTG will be held February 20-24, 2017 in Atlanta, GA at the 
downtown Sheraton Hotel
  *   Our group rate for rooms is $185 a night (which includes a breakfast 
buffet)
  *   Registration will go live in the next couple of weeks and tickets will be 
$100, which will help cover lunch/coffee every day and help us ensure 
attendance for those that register
  *   Horizontal/cross project teams will meet Monday and Tuesday, Vertical 
project team meetings will be held Wednesday, Thursday and Friday

For anyone going to the Summit in Barcelona later this month, Thierry and I 
will be hosting an informational presentation on the 
PTG
 and then answering questions in the Foundation Lounge (located near the main 
entrance of the Convention Center near Registration) on Wednesday 10/26 during 
lunch from 1:05-1:35pm. Feel free to stop by to learn more or ask us questions, 
and stay tuned for more information in the coming weeks.

Erin Disney
OpenStack Marketing
e...@openstack.org



-- Forwarded message -
From: Clint Byrum >
Date: Thu, Oct 13, 2016 at 8:42 AM
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes
To: openstack-dev 
>


Excerpts from Dmitry Tantsur's message of 2016-10-13 10:30:44 +0200:
> On 10/12/2016 08:47 PM, Clint Byrum wrote:
> > Excerpts from Jaesuk Ahn's message of 2016-10-12 15:08:24 +:
> >> It can be cheap if you are in the US. However, for Asia folks, it is not
> >> that cheap considering it is all overseas travel. In addition, all-in-one
> >> event like the current summit makes us much easier to get the travel fund
> >> from the company, since the company only need to send everyone (tech, ops,
> >> business, strategy) to one event. Even as an ops or developers, doing
> >> presentation or a meeting with one or two important company can be very
> >> good excuse to get the travel money.
> >>
> >
> > This is definitely on the list of concerns I heard while the split was
> > being discussed.
> >
> > I think the concern is valid, and we'll have to see how it affects
> > attendance at PTG's and summits.
> >
> > However, I am not so sure the overseas cost is being accurately
> > characterized. Of course, the complications are higher with immigration
> > details, but ultimately hotels around international hub airports are
> > extremely cheap, and flights tend to be quite a bit less expensive and
> > more numerous to these locations. You'll find flights from Narita to
> > LAX for < $500 where as you'd be hard pressed to find Narita to Boston
> > for under $600, and they'll be less convenient, possibly requiring more
> > hotel days.
>
> The bit about hotels contradicts my whole experience. I've never seen hotels 
> in
> big busy hubs cheaper than in less popular and crowded cities. Following your
> logic, hotels e.g. in Paris should be cheaper than ones in e.g. Prague, which 
> I
> promise you is far from being the case :)
>

Sorry I communicated that horribly.

The hotels next to LAX, which are _ugly_ and _disgusting_ but perfectly
suitable for a PTG, are much cheaper than say, the ones in DT LA near the
convention center, or in Hollywood, or near Disneyland.

A better comparison than LAX might be Atlanta or Minneapolis, which
are cities that aren't such common end-destinations, but have tons of
flights in and out and generally affordable accommodations.

> >
> > Also worth considering is how cheap the space is for the PTG
> > vs. Summit. Without need for large expo halls, keynote speakers,
> > catered lunch and cocktail hours, we can rent a smaller, less impressive
> > space. That should mean either a cheaper ticket price (if there is one
> > at all) or more sponsored travel to the PTG. Either one of those should
> > help alleviate the concerns about travel budget.
>
> For upstream developers 

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[John Davidge]

Steve,

Why just the one summit? Each cycle has a PTG and a summit, which makes 4 
events per year.

John

From: "Steven Dake (stdake)" >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, October 12, 2016 at 3:25 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

Clint,

RE 3 - I do understand purpose of PTGs.   Prior many engineering orgs didn't 
send many people to midcycles (where a lot of work got done - more so than 
summit even).  The 3 events are 2 PTGS + 1 summit (although I don't know the 
length of the PTGs)

Regards
-steve


From: Clint Byrum >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, October 12, 2016 at 12:51 AM
To: openstack-dev 
>
Subject: Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

Excerpts from Steven Dake (stdake)'s message of 2016-10-12 06:42:43 +:
Tom,
No flame, just observation about the reality of these changes.
I think we missed this communication on the mailing list or in the FAQs or 
somewhere else.  I think most engineering-focused organizations are looking at 
the PTGs only and not really considering the summit for budget planning.  If 
folks knew the operators were only going to be at the OpenStack Summit, I think 
that may change budget planning for engineering organizations.  Seems like more 
siloing to me, not less.  We need to integrate OpenStack's development with 
Operators as well as the Operator's customers (the cloud consumers the 
Operators deliver to).
Does the foundation not want to co-locate the ops summit at the PTG because the 
ops summit feeds into the OpenStack Summit main ops day(s)?

Agree, on the surface it looks like this adds a brick or two on top of
the existing wall that devs throw things over.

However, I think the reality is those bricks were already there, and
we've all been pretending this isn't what is already happening.

So, while I do want to make sure enough of our architects and designers
go to the summit to truly understand user needs, I also think it has
been proven ineffective to also throw all of the coders into that mix and
expect them to be productive.

I recall many of us huddled in the dev pit and at parties at summits
trying desperately to have deep technical conversations while the
maelstrom was happening around us. And then the few who were fortunate
enough to go to the mid-cycle would get into quiet rooms for a few days,
and _actually_ design the things our users need, but 3 months late,
and basically for the next release.

I don't have any easy solutions for this problem, but the expectation that 
project developers are required at 3 week-long events instead of 2 wasn't 
clearly communicated and should be rectified beyond a post to the openstack-dev 
mailing list where most people filter messages by tags (i.e. your message is 
probably not reaching the correct audience).

Where did you get three?

PTG - write code, design things (replaces mid-cycles)
Summit - listen to users, showcase designs, state plans for next release

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



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PTG from the Ops Perspective - a few short notes

[John Davidge]

On 10/12/16, 11:18 AM, Dmitry Tantsur wrote:

>On 10/12/2016 11:59 AM, Thierry Carrez wrote:
>>
>> PTGs happen in more cost-effective locations, airport hubs with cheaper
>> hotels, which should lower the cost of attending. Yes, I'm pretty sure
>> traveling to Atlanta downtown for a week will be cheaper than going to
>> Barcelona, Boston or Sydney downtown for a week.
>
>[...]
>
>And while PTG will surely be cheaper than the Summit, the Summit is not
>going
>away (for marketing, management, few developer representatives), so the
>total
>expense is unlikely to drop IMO.

Yes, I've been unsure about the cost justification for the PTG too.
Hosting in a less expensive city will probably result in the PTG being
slightly cheaper to attend than the Summit, but with ops feedback and so
many other important activities missing, many developers will need to
attend both the Summit and the PTG to be fully involved.

Cost of PTG < Cost of Summit

But:

(Cost of PTG + Cost of Summit) > Cost of Summit

Also, unless I've missed something, we still don't know the registration
fees for the PTG and the new Summit do we? Last I remember, there was talk
of a registration fee for the PTG, and then a Summit discount for PTG
attendees[1]. Is that still the plan?

Surely the PTG will need to be free to attend, otherwise isn't it better
for project teams to simply shift our existing mid-cycles to the PTG
timeframe with an altered focus to save money? Genuine question.


>[...]
>>
>> Yes, the plan is (amongst other things) to make sure that upstream
>> developers are available to interact with users (operators, but also app
>> developers...) during the very week where *all* our community gets
>> together (the OpenStack Summit). Currently we try to get things done at
>> the same time, which results in hard choices between listening and
>> doing. By clearly setting out separate times for each activity, we make
>> sure we stay focused.
>
>Sorry, but to me it's extremely unrealistic to expect a big number of
>developers
>on the Summit any more. Sending folks to both events doubles the travel
>budget,
>and I know that many companies have struggles with sending people to one
>event
>already.

I know a lot of people share this concern. It can already be hard enough
to justify travel twice a year to an event comprising 100% of the
community's activities. Splitting that 100% across two separate events of
~50% each, twice each per year, is going to make it much harder. I fear
that some developers will be unable to attend any events at all, as
neither the PTG or the new Summit will be as important as the combined
Summit has been until now.

I'm looking forward to hopefully hearing a lot more details about the PTG
during the summit.

Thanks,

John

[1] https://www.openstack.org/ptg/ptgfaq/



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [all][elections] Results of the TC Election

[John Davidge]

On 10/10/16, 5:36 AM, Monty Taylor wrote:

>It's really nice to see that we had an increase in turnout percentage
>even in the face of having our largest electorate yet.
>
>Thanks for all your great work!!!
>
>Monty

+100

Thank you as well to all the candidates and standing TC members who took
part in this process. The past few weeks have really opened my eyes to
what our TC deals with day-to-day, and the huge amount of work that goes
into making things run smoothly.

Special thanks to Thierry and Doug in particular for what was at times a
heated debate. I have a lot to learn from you both about keeping a level
head on the ML :)

Cheers and congrats,

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [elections][tc]Thoughts on the TC election process

[John Davidge]

Thierry Carrez wrote:

>Edward Leafe wrote:
>> [...]
>> The current candidacy essay would now be posted in the campaign period,
>>rather than at the time of nomination, and should exclude the sort of
>>biographical information that is currently the most important piece for
>>many people. [...]
>
>As other mentioned, this is unlikely to give good results -- the track
>record of the person is much more important than what they pretend to
>care about in campaign emails (or their mastery of written English).

Is it, though? A person's track record might help to show how likely they
are to stick to their stated goals, but it's the goals themselves that are
actually going to shape the future of OpenStack. Ed quite rightly points
out that our current election system puts almost no focus on the agenda of
each candidate, in favor of how well their name is recognized by a wide
base of contributors. I do agree that name recognition in itself can be an
indication that the person has contributed and will continue to contribute
positively to the community, but it shouldn't be the primary metric.

On balance, I think that the community would benefit from an effort to
shift the focus more onto the issues than the individuals. The TC would
also benefit by receiving a greater mandate to accomplish the goals that
were voted for.

We'll need to acknowledge that the more well known names in the community
you would stand to lose a large advantage with the change Ed is proposing.
If we're going to seriously consider some level of electoral reform - and
I think we should - then it needs to be discussed and refined in the open,
and decided by community vote. The TC cannot be the ones to decide this,
as no matter how much we trust them, we cannot ignore the conflict of
interests it raises.

Thierry, I'm surprised by your open hostility towards candidates. Accusing
people of 'pretending' to care about things that they've taken the time to
write about is exactly the kind of bad-faith assumption that puts people
off from getting involved. This leads to self-censorship of dissent,
without which it is impossible to have any meaningful debate. I wish we
could disagree without resorting to personal attacks.

>In campaign emails, people always promise they have a lot of time on their
>hands, or they will change everything (or "be proactive"). But when the
>rubber hits the road, some vote one hour before the meeting, and some
>others don't show up at all. Campaign emails only bind those who believe
>in them. In my voting I prefer to consider the past availability and
>interest in those issues, the positions held on various threads and
>reviews, and the cooperative behavior (or absence thereof) exhibited in
>those discussions.

All valuable methods for weighing candidates against each other, which is
why I don't think dropping names completely is the right way to go. Again
though, let's not encourage the assumption that all candidates are lazy
con-artists until proven otherwise.

>Now, it's true that a lot of people vote on names, and don't take the
>time to dig into meeting logs and governance reviews. I'm not sure it's
>easy to fix though... you can't force people to spend time researching
>candidates.

And I don't think we have to. Something as simple as a few bullet points
about each candidate's intentions on the voting page would be a hugely
beneficial first step. If the current voting infrastructure doesn't
support that for whatever reason, then we should consider a different one.

>We could reduce the electorate to people more likely to have
>time to do that research (raise the bar in number of patches you have to
>contribute before you can vote) -- but that would require significant
>changes in the Foundation bylaws (where the "1 contributor = 1 vote"
>principle in carved in protected sections).

No, absolutely not. We went over this on the 'Write down OpenStack
principles' review[1]. The fact that the required research is so time
consuming is the problem. We should be making every effort to present the
relevant information at the time of voting. Of course this is easier said
than done, but if we don't help newer contributors feel like they're
making informed voting decisions, we're going to lose out on the
opportunity for our ever-changing demographics to inform our direction.

>Another path would be to facilitate that research. We could publish
>meeting presence metrics, but that would only encourage people to make
>random noise at meetings. We could ask incumbents to post a "here is
>what I did over the last year at the TC" as part of their platform
>email. Other ideas ?

I think a beneficial step would be to include the community earlier in the
process. A poll in the weeks leading to the self-nomination period could
be used to identify the issues people are most concerned about, and
candidates could be encouraged to address those issues directly in their
self-nominations. This would reduce the reliance on a potentially messy

Re: [openstack-dev] [all][elections][TC] TC Candidacy

[John Davidge]

Hi Zane,

Thanks for pointing this out! My interpretation of the StackForge
Retirement page[1] was wrong on that point. I've updated the blog post to
reflect that (without removing the original interpretation).

The discussion about renaming git repos is a bit of a red herring, because
what we're really talking about is what it *means* to be in Stackforge vs.
OpenStack vs. OpenStack Family, not which git namespace a project should
live in. Apologies if I didn't make that clear.

Like many of us, I do my best to keep up with historical context, but when
there is so much contradictory information/opinion out there about what
OpenStack is/isn't was/wasn't it can be a struggle at times. The crux of
my proposal is aiming to solve that by not trying to be everything to
everyone under one tent - by defining sensible boundaries to separate the
different goals of the community.

All the best,

John

[1] https://wiki.openstack.org/wiki/Stackforge_Namespace_Retirement

On 9/27/16, 5:13 PM, Zane Bitter wrote:

>On 27/09/16 06:19, John Davidge wrote:
>>> Having Stackforge as a separate Github organization and set of
>>> >repositories was a maintenance nightmare due to the awkwardness of
>>> >renaming projects when they "moved into OpenStack".
>> There's no reason that this would need a separate github structure, just
>> separate messaging and rules.
>
>That's exactly what we have now.
>
>This statement on your blog:
>
>"[StackForge] was retired in October 2015, at which point all projects
>had to move into the OpenStack Big Tent or leave entirely."
>
>is completely false. That never happened. There are still plenty of
>repos on git.openstack.org that are not part of the Big Tent. At no time
>has any project been required to join the Big Tent in order to continue
>being hosted.
>
>Maybe you should consider reading up on the historical background to
>these changes. There are a lot of constraints that have to be met - from
>technical ones like the fact that it's not feasible to rename git repos
>when they move into or out of the official OpenStack project, to legal
>ones like how the TC has to designate projects in order to trigger
>certain rights and responsibilities in the (effectively immutable)
>Foundation by-laws. Rehashing all of the same old discussions without
>reference to these constraints is unlikely to be productive.
>
>cheers,
>Zane.
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [all][elections][TC] TC Candidacy

[John Davidge]

Thanks for the questions Jay, answers inline.

On 9/26/16, 8:39 PM, Jay Pipes wrote:
>Who decides what is integral to OpenStack and what merely "enhances" it,
>though? The TC? The DefCore group? The Board of Directors? One might say
>all three groups have a say in defining what "is OpenStack", no? And
>therefore all three groups would decide what is "integral" to OpenStack.

This will undoubtedly be the most difficult part of the transition, so
making these decisions transparently will be essential. As a starting
point I would suggest we use our existing definitions of Core and Optional
services found here: https://www.openstack.org/software/

Everything in the 'Core' section would fall within the definition of
OpenStack, everything else would live in the OpenStack Family. This isn't
a change that would happen overnight, and of course we¹d seek many rounds
of input from all interested parts of the community.

>We do indeed have a long way to go in improving the operator's
>experience for many OpenStack projects.
>
>However, remember that many of the OpenStack projects came into
>existence because operators were asking for a certain use case to be
>fulfilled. I'm uncertain how putting some projects into a
>not-really-OpenStack-but-related bucket will help operators much. Is the
>pain for operators that there are too many projects in OpenStack, or is
>the pain that those projects are not universally installable or usable
>in the same fashion?

Absolutely, listening to operators should continue to be the primary
driver for a lot of our decision making. For the last 3 or 4 summits I've
found the operator feedback sessions to be the most valuable, and at least
one led directly to a new feature (neutron purge).

Not being an operator myself I'd defer to seeking feedback from the ops
community during this process, but a few Big Tent related issues I've
heard include:

* Do I need to support *all* of these projects?
* Why doesn¹t everything follow the same release schedule any more?
* How many of these are mature enough to be useful?

>What is OpenStack's core purpose? :) The OpenStack mission is
>intentionally encompassing of a wide variety of users and use cases. The
>Big Tent, by the way, did not affect this fact. The OpenStack mission
>pre-exists the Big Tent. All the Big Tent did was say that projects that
>wanted to be official OpenStack projects needed to follow the 4 Opens,
>submit to TC governance, and further the mission of OpenStack.
>
>It sounds like you would like to limit the scope of the OpenStack
>mission, which is not the same as getting rid of the Big Tent. If that's
>the case, hey, totally cool with me :) But let's be specific about what
>it is you are suggesting.

OpenStack does not have a core purpose. Not one that everyone agrees on
anyway. Some would like it to be an Apache-like collection of loosely
related open source projects. Others would like to see it be a
laser-focused operating system for the data center. I'd say that it
started out closer to the latter and is slowly drifting towards the
former. The discussion surrounding the "Write down OpenStack Principles"
patch has shown us that the closest we've had to an official mission
statement until now was the result of a TC vote in 2011:

"A single product made of a lot of independent, but cooperating,
components."

Now obviously this is somewhat vague and open to interpretation, but to me
the "single product" part suggests a level of focus that is missing today.
This puts us in the position of deciding whether we need to re-focus
OpenStack to better match the mission statement, or change our mission
statement to better reflect reality. I'd like to do a bit of both. Limit
the scope of OpenStack to that of its core components, while providing a
framework for official projects that enhance its capabilities.


>Hmm, I disagree about that. I think that experience actually *has* shown
>us that there is a single set of rules that can/should be applied to all
>projects that wish to be called an OpenStack project.

We may have to agree to disagree here. Look at recent efforts to enforce
python 3 compatibility, for example. Some projects had reasons why they
didn't want to, others had reasons why they couldn't, and some simply
didn't view it as a priority. We'd be much more productive in defining and
enforcing rules like this if there was a narrower scope of projects they
applied to.

>> * Define OpenStack as its core components
>
>Which components would these be? Folks can (and will) argue with you
>that a particular service is critical and should be considered core. But
>differing opinions here will lead to a decision-making inertia that will
>be difficult to overcome. You've been warned. :)

See above. This definition already exists, but I acknowledge that it will
need to be iterated upon. I'd like to point out that there will be
benefits of being in the OpenStack Family, such as not needing to comply
with the more prescriptive rules as 

[openstack-dev] [all][elections][TC] TC Candidacy

[John Davidge]

Hi everyone,

I'd like to submit my candidacy for the OpenStack Technical Committee. You
may know me as john-davidge on IRC.

I've been an active member of the OpenStack community since 2012 (Folsom).
I met many of you for the first time while presenting the Curvature Network
Visualization Dashboard[1] at the Grizzly Summit in Portland. Since then
I've been working 100% upstream, mostly in neutron[2][3], and for a couple
of different sponsors. Right now I'm employed in the OpenStack Innovation
Center (OSIC) - a joint venture between Rackspace and Intel - where I'm
leading a small team contributing to neutron, and helping to shape the OSIC
development roadmap. Over the years I have seen and participated in a lot
of the changes that have led our community to where it is today. I've
experienced the things that have improved our lives as developers, and
operators, as well as the things that have caused us difficulties.

I know where I would like to see OpenStack head in the future, and I feel
strongly about making it a success. The most important thing that I would
like to see changed is the overarching framework under which all of
OpenStack operates:

The Big Tent.

Last year, the TC moved OpenStack away from the Integrated Release, and
into The Big Tent. This removed the separation between those projects
considered integral to OpenStack, and those which enhance it. Since then,
the number of official projects has gone from ~12 to 60. While this was a
fantastic move for community inclusivity, it has also made life harder for
operators and customers, and has diminished the focus on OpenStack's core
purpose.

Managing every team under one roof has led to issues for both the core and
the newer projects. The experience so far has taught us that there isn't a
single set of rules that can be helpfully applied to both. I believe that
now is the time to take The Big Tent's ideas and iterate upon them to
create a new model that can promote inclusivity, while still preserving a
clear focus for the core of OpenStack. The main points of this new model
are:

* Define OpenStack as its core components
* Introduce a new home for complementary projects - The OpenStack Family
* Reinstate Stackforge as the primary incubator for new projects

OpenStack will once again be a focused set of closely aligned projects
working together to provide an operating system for the datacenter. The
OpenStack Family will provide a home for projects that work to improve the
experience of an OpenStack cloud (think Ceilometer, Heat, etc), while
protecting them from some of the more prescriptive rules that go with being
a core OpenStack component. Stackforge will be the main focus of
early-stage innovation, with a clearly defined path towards graduation into
The OpenStack Family. I believe that this model[4] can go a long way
towards solving many of the pain points that we are seeing with OpenStack
today.

This transformation is one that I think is very important for the future
of OpenStack. We have a fantastic project surrounded by a talented
community, of which I am very proud to call myself a member. Trust me with
your vote, and I'll work hard to ensure its continued success.

Thank you for your consideration,

John

[1] https://www.youtube.com/watch?v=pmpRhcwyJIo - Curvature
[2] https://www.youtube.com/watch?v=GjuF-3fB0IQ - IPv6 Prefix Delegation
[3] https://www.youtube.com/watch?v=4ag1NiCVBDo - Neutron Purge
[4] https://johndavidge.wordpress.com/mr-openstack-tear-down-this-tent/


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Skip-only tests

[John Davidge]

John Schwarz wrote:

>Hi all,
>
>The Neutron community has recently started contributing Tempest
>scenario tests in the Neutron tree and I'd like to discuss a general
>issue we're hitting. Mainly, we're talking about required hardware for
>some features and/or VM images that support more features, which makes
>it hard (or impossible) to test certain features at the gate
>end-to-end. Specifically, tests that require SR-IOV or OVS-DPDK, and
>tests relating to VLAN Aware VMs.
>[Š]

Resurrecting this thread with another example where this would be useful:

IPv6 Prefix Delegation

This feature still lacks end-to-end testing because it depends upon having
a compatible DHCPv6 server installed and running with an appropriate
config, and specifically dibbler[1] to act as the DHCPv6 client.

I¹d be interested in assisting with this effort.

John

[1] https://github.com/tomaszmrugalski/dibbler




Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

[John Davidge]

Jay Pipes wrote:

>[…]
>The TC doesn't comply with anything at all. It's the body that is
>elected to make overarching governance decisions for the OpenStack
>community.

Sure, that's an important distinction. My point is that when governance
decisions are made that seem to contradict each other, it can be difficult
to follow.

>> This is the
>> moment that OpenStack stopped being: ³A single product made of a lot of
>> independent, but cooperating, components.² And became: ³A collection of
>> independent projects that work together for some level of integration
>>and
>> releases.²
>
>You are mistaken, I'm sorry to say.

That's entirely possible. The review we're all debating highlights that
the intentions and realities of OpenStack are not easy to agree upon.

>Firstly, your statement that OpenStack stopped being "a single product"
>at some point is just flat-out wrong. It never *was* a single product,
>regardless of whether some time in 2011 seven individuals on the project
>policy board said that that was the direction they preferred the
>community to go in.

As Thierry pointed out, 'A single product made of a lot of independent,
but cooperating, components' is the closest thing we currently have to a
common philosophy. The review[1] in question is attempting to codify this
into our governance policies. The opinion of the TC seems to be that this
is what were currently are. I disagree with that assessment - it sounds
like you do as well. I take your point about OpenStack never being a
single product to begin with. The distinction I would make is that The Big
Tent was the first time a governance decision was made to undermine that
goal.

>Secondly, the Big Tent was about changing the process by which new
>projects applying to become "OpenStack projects" were evaluated by the
>TC. We went from a situation of evaluating new projects using
>subjective, often contradicting and changing opinions on architectural
>and software design to instead evaluating new project teams on whether
>the project team followed "The OpenStack Way" (followed the 4 Opens and
>furthered the mission of OpenStack)
>
>The Big Tent **was not a redefinition of what OpenStack was or is**.

In theory, perhaps. In practice, I'd say that it was. Prior to The Big
Tent there was a clear distinction between which projects were OpenStack,
and which projects were OpenStack-in-waiting (Stackforge). A problem that
The Big Tent seemed to be solving was that there wasn't always a clear
path for a given Stackforge project to become an OpenStack project. I
don't think the problem was the path, but the goal. The expectation was
that Stackforge projects would eventually graduate into OpenStack
projects, but with the definition/requirements of OpenStack at the time
that didn't always make sense. So we changed what it meant to be an
OpenStack project. Perhaps what we should have done is define a new place
for such projects to land.

>Sounds to me like you are just complaining about OpenStack having too
>many projects in it. If so, please tell us which projects you would have
>leave OpenStack.

Yes, that's a part of what I'm saying. After writing my first reply I
decided there wasn't much point talking about the problem without
proposing a solution, so I wrote one[2]. Essentially it boils down to:

* Abolish The Big Tent
* Define OpenStack as its core components
* Create a new place for complimentary projects to live
* Bring back Stackforge

The link[2] below goes into a lot more detail, and I'd love to hear
feedback from all interested parties.

>My vote is definitely for something #2-like, as I've said before and on
>the review, I believe OpenStack should be a "cloud toolkit" composed of
>well-scoped and limited services in the vein of the UNIX model of do one
>thing and do it well. I believe that vendors and cloud providers should
>be able to choose services and tools from this OpenStack cloud toolkit
>to build clouds, cloud products, and products that utilize OpenStack
>service APIs to please customers.

So it seems we both agree that the current definition doesn't fit, even if
we don’t agree on the solution :)

Thanks,

John

[1] https://review.openstack.org/#/c/357260
[2]
https://johndavidge.wordpress.com/2016/09/09/mr-openstack-tear-down-this-te
nt/



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

Re: [openstack-dev] [all] governance proposal worth a visit: Write down OpenStack principles

[John Davidge]

Thierry Carrez wrote:

>[...]
>In the last years there were a lot of "questions" asked by random
>contributors, especially around the "One OpenStack" principle (which
>seems to fuel most of the reaction here). Remarks like "we should really
>decide once and for all if OpenStack is a collection of independent
>projects, or one thing".
>
>A lot of people actually ignore that this question was already asked,
>pretty early on (by John Dickinson in June 2011). Back then it was
>settled by the PPB (the ancestor to the TC). You can read it all
>here[1]. It was never brought again as a proposed change to the TC, so
>that decision from June 2011 is still defining how we should think about
>OpenStack.
>
>Most of the TC members know the governance history and know those
>principles. That is, after all, one of the reasons you elect them for.
>But we realized that the people asking those questions again and again
>were not at fault. It was our failure to *document* this history
>properly which caused the issue. Took us some time to gather the courage
>to write it, then finally Monty wrote a draft, and I turned it into a
>change.

To provide a counter point, I think the reason this question is asked so
often is not because the TC has failed to *document* this policy, but that
it has failed to *comply* with it.

I¹m of course referring to the introduction of The Big Tent. This is the
moment that OpenStack stopped being: ³A single product made of a lot of
independent, but cooperating, components.² And became: ³A collection of
independent projects that work together for some level of integration and
releases.²

This is in direct contradiction to the stated and collectively understood
goal of the project, and has left many scratching their heads.

The principles as written in the review do not accurately describe the
current state of the project. To make it so that they do, we either need
to change the principles or change the project. As I see it, our options
are:

1. Adjust the project to reflect the principles by abolishing The Big Tent.
2. Adjust the principles to reflect the project by redefining it as: ³A
collection of independent projects that work together for some level of
integration and releases.²

Personally, my vote is for option 1.

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

[openstack-dev] [OSC] Tenant Resource Cleanup

[John Davidge]

Hello,

During the Mitaka cycle we merged a new feature into the python-neutronclient 
called 'neutron purge'. This enables a simple CLI command that deletes all of 
the neutron resources owned by a given tenant. It's documented in the 
networking guide[1].

We did this in response to feedback from operators that they needed a better 
way to remove orphaned resources after a tenant had been deleted. So far this 
feature has been well received, and we already have a couple of enhancement 
requests. Given that we're moving to OSC I'm hesitant to continue iterating on 
this in the neutron client, and so I'm reaching out to propose that we look 
into making this a part of OSC.

Earlier this week I was about to file a BP, when I noticed one covering this 
subject was already filed last month[2]. I've spoken to Roman, who says that 
they've been thinking about implementing this in nova, and have come to the 
same conclusion that it would fit better in OSC.

I would propose that we work together to establish how this command will behave 
in OSC, and build a framework that implements the cleanup of a small set of 
core resources. This should be achievable during the Ocata cycle. After that, 
we can reach out to the wider community to encourage a cross-project effort to 
incrementally support more projects/resources over time.

If you already have an etherpad for planning summit sessions then please let me 
know, I'd love to get involved.

Thanks,

John

[1] http://docs.openstack.org/mitaka/networking-guide/ops-resource-purge.html
[2] 
https://blueprints.launchpad.net/python-openstackclient/+spec/tenant-data-scrub


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [api][doc][neutron] what releases should API reference support?

[John Davidge]

On 9/6/16, 2:02 PM, "Ihar Hrachyshka"  wrote:

>Akihiro Motoki  wrote:
>
>> What releases should we support in API references?
>> There are several options.
>>
>> 1. The latest stable release + master
>> 2. All supported stable releases + master
>> 3. more older releases too?
>>
>> Option 2 sounds reasonable to me.
>>
>> This question is raised in the neutron api-ref patch [1].
>> This patch drops the API reference of LBaaS v1 which was dropped in
>> Newton release.
>> At least Newton is not released yet, so I think it is better to keep
>> it until Newton is released.
>>
>> I would like to get a community consensus before moving this patch
>>forward.
>>
>> Thanks,
>> Akihiro
>
>Since neutron-lib is branched on stable/* boundary, I feel that it would
>be
>fine to keep one-to-one relationship between neutron and neutron-lib
>api-ref branches.
>
>The only reason why keeping all stable branches described in master would
>
>be ease of maintenance, because you don¹t need to backport any api-ref
>related fixes to previous branches.
>
>So, I would not vote for any of 3 options suggested. Instead, I would
>keep
>master api-ref documenting just the latest (master) neutron API, and keep
>
>stable releases documented in corresponding branches whenever they differ.
>
>Of course it will require to solve an issue of publishing api-ref for
>each
>of supported branches instead of just master.
>
>Ihar

I¹m inclined to agree with Ihar on this. Now that the api ref lives in
neutron-lib I think it makes sense for it to track master. If it lived
elsewhere and wasn¹t so closely coupled with release branches then option
2 would be best, but as Ihar says, the ref for older releases can belong
in the relevant branch.

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [neutron] OVO Status Dashboard

[John Davidge]

Thanks Victor,

This is a nice way to track the work. If this is going to replace the
etherpad[1] then can I suggest including links to reviews in place of the
In Progress/Done text for each entry? The color coding will preserve the
completion status.

John

[1] https://etherpad.openstack.org/p/newton-ovo-progress

On 8/12/16, 4:15 PM, "Morales, Victor"  wrote:

>Hey neutrinos,
>
>First of all, the high priority for OVO implementation in newton release
>are
>the implementation and integration of port, subnet and network objects,
>but
>given that more people is joining to this initiative and also many
>patches are
>related directly and indirectly to this, results in something hard to
>track.
>So, I decided to create this document[1] to visualize and coordinate
>efforts.
>Feel free to include, modify or add missing things but even more try to
>review
>existing patches and help us to achieve our goal.
>
>[1]
>https://docs.google.com/spreadsheets/d/1FeeQlQITsZSj_wpOXiLbS36dirb_arX0XE
>WBdFVPMB8/edit?usp=sharing
>
>Regards/Saludos
>Victor Morales
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [neutron][dvr][fip] fg device allocated private ip address

[John Davidge]

Yes, as Brian says this will be covered by the follow-up patch to [2]
which I¹m currently working on. Thanks for the question.

John


On 8/1/16, 3:17 PM, "Brian Haley"  wrote:

>On 07/31/2016 06:27 AM, huangdenghui wrote:
>> Hi
>>Now we have spec named subnet service types, which provides a
>>capability of
>> allowing different port of a network to allocate ip address from
>>different
>> subnet. In current implementation of DVR, fip also is distributed on
>>every
>> compute node, floating ip and fg's ip are both allocated from external
>>network's
>> subnets. In large public cloud deployment, current implementation will
>>consume
>> lots of public ip address. Do we need a RFE to apply subnet service
>>types spec
>> to resolve this problem. Any thoughts?
>
>Hi,
>
>This is going to be covered in the existing RFE for subnet service types
>[1].
>We currently have two reviews in progress for CRUD [2] and CLI [3], the
>IPAM
>changes are next.
>
>-Brian
>
>[1] https://review.openstack.org/#/c/300207/
>[2] https://review.openstack.org/#/c/337851/
>[3] https://review.openstack.org/#/c/342976/
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [Neutron] Question about service subnets spec

[John Davidge]

Resurrecting this thread from last week.

On 5/31/16, 10:11 PM, "Brian Haley"  wrote:

>> At this point the enumeration values map simply to device owners.  For
>>example:
>>
>>router_ports -> "network:router_gateway"
>>dvr_fip_ports -> "network:floatingip_agent_gateway"
>>
>> It was at this point that I questioned the need for the abstraction at
>> all.  Hence the proposal to use the device owners directly.
>
>I would agree, think having another name to refer to a device_owner makes
>it
>more confusing.  Using it directly let's us be flexible for deployers,
>and
>allows for using additional owners values if/when they are added.

I agree that a further abstraction is probably not desirable here. If this
is only going to be exposed to admins then using the existing device_owner
values shouldn¹t cause confusion for users.

>
>> Armando expressed some concern about using the device owner as a
>> security issue.  We have the following policy on device_owner:
>>
>>"not rule:network_device or rule:context_is_advsvc or
>> rule:admin_or_network_owner"
>>
>> At the moment, I don't see this as much of an issue.  Do you?
>
>I don't, since only admins should be able to set device_owner to these
>values
>(that's the policy we're talking about here, right?).
>
>To be honest, I think Armando's other comment - "Do we want to expose
>device_owner via tha API or leave it an implementation detail?" is
>important as
>well.  Even though I think an admin should know this level of neutron
>detail,
>will they really?  It's hard to answer that question being so close to
>the code

Seeing as device_owner is already exposed by the port API I don¹t think
this is an issue. And if we agree that a further abstraction isn¹t a good
idea then I don¹t see how we would get around exposing it in this context.

https://review.openstack.org/#/c/300207

John



Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.

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

Re: [openstack-dev] [neutron] gate-neutron-dsvm-api failures

[John Davidge (jodavidg)]

On 1/14/16, 3:04 PM, "Brian Haley" <brian.ha...@hpe.com> wrote:


>On 01/14/2016 05:42 PM, John Davidge (jodavidg) wrote:
>> The 
>>neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTe
>>stJSON
>> test has been consistently failing for patch
>> https://review.openstack.org/#/c/258754/ and I don¹t see how they can be
>> related. This patch has been trying to merge for a month.
>>
>> This test seems to be experiencing a lot of failures recently:
>>
>> 
>>http://status.openstack.org//elastic-recheck/data/uncategorized.html#gate
>>-neutron-dsvm-api
>>
>> Has it been diagnosed? Could somebody more familiar with the test take
>>a look
>> please?
>
>John,
>
>That test was just recently changed too:
>
>https://review.openstack.org/#/c/265016/2/neutron/tests/api/admin/test_flo
>ating_ips_admin_actions.py
>
>So perhaps that change didn't actually fix things.

It¹s failing with tempest_lib.exceptions.ServerFault rather than
tempest_lib.exceptions.Conflict, so that change won¹t have helped in this
case.

John


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

[openstack-dev] [neutron] gate-neutron-dsvm-api failures

[John Davidge (jodavidg)]

The 
neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON 
test has been consistently failing for patch 
https://review.openstack.org/#/c/258754/ and I don't see how they can be 
related. This patch has been trying to merge for a month.

This test seems to be experiencing a lot of failures recently:

http://status.openstack.org//elastic-recheck/data/uncategorized.html#gate-neutron-dsvm-api

Has it been diagnosed? Could somebody more familiar with the test take a look 
please?

Thanks,

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

Re: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka

[John Davidge (jodavidg)]

++

Sounds very sensible to me!

John

From: "Armando M." >
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>
Date: Wednesday, 4 November 2015 21:23
To: "OpenStack Development Mailing List (not for usage questions)" 
>
Subject: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka

Hi folks,

After some consideration, I am proposing a change for the Mitaka release cycle 
in relation to the mid-cycle meetup event.

My proposal is to defer the gathering to later in the release cycle [1], and 
assess whether we have it or not based on the course of events in the cycle. If 
we feel that a last push closer to the end will help us hit some critical 
targets, then I am all in for arranging it.

Based on our latest experiences, I have not seen a strong correlation between 
progress made during the cycle and progress made during the meetup, so we might 
as well save us the trouble of travelling close to Christmas.

I'd like to thank Kyle, Miguel Lavalle and Doug for looking into the logistics. 
We may still need their services later in the new year, but as of now all I can 
say is:

Happy (distributed) hacking!

Cheers,
Armando

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

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

[John Davidge (jodavidg)]

Hi Edgar,

Happy to continue contributing here.  Currently in GMT timezone, but probably 
PST by the end of the year. Looking forward to the first meeting!

Cheers,

John Davidge

From: Edgar Magana <edgar.mag...@workday.com<mailto:edgar.mag...@workday.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, 8 October 2015 01:11
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>, 
"openstack-operat...@lists.openstack.org<mailto:openstack-operat...@lists.openstack.org>"
 
<openstack-operat...@lists.openstack.org<mailto:openstack-operat...@lists.openstack.org>>,
 
"openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>" 
<openstack-d...@lists.openstack.org<mailto:openstack-d...@lists.openstack.org>>
Subject: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for 
contributors

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

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

Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

[John Davidge (jodavidg)]

We seem to be agreeing that having third party CI tools not vote –1 is a good 
idea. Personally I think it would be more beneficial to make it a rule rather 
than a recommendation.

John

From: Edgar Magana edgar.mag...@workday.commailto:edgar.mag...@workday.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, 26 June 2015 19:04
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Totally agreed!

Edgar

From: Salvatore Orlando
Reply-To: OpenStack Development Mailing List (not for usage questions)
Date: Thursday, June 25, 2015 at 3:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

Edgar,

in a nutshell my point is that if we want to remove voting rights from every CI 
I'm fine with it.
However, I think what's being discussed in this thread is already captured very 
well by [1] and believe the policy it outlines is perfectly fine for Neutron 
purposes.

Salvatore

[1] 
http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/thirdparty-ci.rst

On 25 June 2015 at 17:08, Edgar Magana 
edgar.mag...@workday.commailto:edgar.mag...@workday.com wrote:
Thank for your response Salvatore. I am not sure what is your position in this 
topic? Are you fine removing voting rights to all Cis?

Edgar

From: Salvatore Orlando
Reply-To: OpenStack Development Mailing List (not for usage questions)
Date: Thursday, June 25, 2015 at 7:59 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [openstack-infra] [neutron] Third Party CI Voting



On 25 June 2015 at 16:08, John Davidge (jodavidg) 
jodav...@cisco.commailto:jodav...@cisco.com wrote:
Hi all,

Recent neutron third party CI issues have got me thinking again about a topic 
which we discussed in Vancouver:

Should any Third Party CI have voting rights for neutron patches in gerrit?

Why should this be a decision for Neutron only?


I’d like to suggest that they shouldn’t.

A -1 from a third party CI tool can often be an indication that the CI tool 
itself or the third party plugin is broken, rather than there being issues with 
the patch under review. I don’t think there are many cases where a third party 
CI tool has caught a genuine issue that Jenkins has missed. With the current 
voting rights these CI tools cause a lot of noise when they experience problems.

As far as I am aware no 3rd party CI tool has a better coverage than the 
upstream one.
some 3rd party CIs exercise different code paths and might uncover some issue 
that the upstream CI did not cover. There will surely be people claiming this 
has happened a lot of times, and even a single issue found is invaluable; I 
would agree with that, but I also think that a 3rd party CI does not have to 
vote to be useful.

I’m not suggesting that the results of these tests be removed from the page 
altogether - there are some cases where their results are useful to the patch 
author/reviewer - but removing voting rights (or at least -1 rights) would save 
a patch from a –1 that might not be particularly meaningful.

Frankly I find the overwhelming number of CI messages - and email notifications 
even more annoying that random -1s. Thankfully you can hide the formers and 
filter out the latters.
From the perspective of 3rd party CI maintainer I could use myself as an 
example; I maintain a CI which has now been broken for about 48 hours. I am 
busy with other tasks and cannot look at it now. I might be a terrible person 
for this, but that's my problem. If the CI was not voting at least I would not 
have annoyed people. (fwiw, I've disabled my CI now).

Also, I believe we already agreed that a working CI is not anymore a 
requirement, as long as the plugin/driver maintainers can provide a reasonable 
proof that their integration works?

Salvatore


Thoughts?

John

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



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


__
OpenStack Development Mailing List (not for usage questions

[openstack-dev] [openstack-infra] [neutron] Third Party CI Voting

[John Davidge (jodavidg)]

Hi all,

Recent neutron third party CI issues have got me thinking again about a topic 
which we discussed in Vancouver:

Should any Third Party CI have voting rights for neutron patches in gerrit?

I’d like to suggest that they shouldn’t.

A -1 from a third party CI tool can often be an indication that the CI tool 
itself or the third party plugin is broken, rather than there being issues with 
the patch under review. I don’t think there are many cases where a third party 
CI tool has caught a genuine issue that Jenkins has missed. With the current 
voting rights these CI tools cause a lot of noise when they experience problems.

I’m not suggesting that the results of these tests be removed from the page 
altogether - there are some cases where their results are useful to the patch 
author/reviewer - but removing voting rights (or at least -1 rights) would save 
a patch from a –1 that might not be particularly meaningful.

Thoughts?

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

Re: [openstack-dev] [neutron] IPv4 transition/interoperation with IPv6

[John Davidge (jodavidg)]

On the subject of Prefix Delegation - yes, the external system is
responsible for the routing. Here¹s a couple of video guides on using
PD in Neutron and setting up the Prefix Delegation Server (in this case
a dibbler server):

Using Neutron PD: https://www.youtube.com/watch?v=wI830s881HQ

Configuring the PD server: https://www.youtube.com/watch?v=zfsFyS01Fn0

The patch is up for review at: https://review.openstack.org/#/c/158697

And the networking guide docs: https://review.openstack.org/#/c/178739

John

On 06/05/2015 17:57, Carl Baldwin c...@ecbaldwin.net wrote:


On Wed, May 6, 2015 at 12:46 AM, Mike Spreitzer mspre...@us.ibm.com
wrote:
 While I am a Neutron operator, I am also a customer of a lower layer
network
 provider.  That network provider will happily give me a few /64.  How
do I
 serve IPv6 subnets to lots of my tenants?  In the bad old v4 days this
would
 be easy: a tenant puts all his stuff on his private networks and NATs
(e.g.,
 floating IP) his edge servers onto a public network --- no need to align
 tenant private subnets with public subnets.  But with no NAT for v6,
there
 is no public/private distinction --- I can only give out the public v6
 subnets that I am given.  Yes, NAT is bad.  But not being able to get
your
 job done is worse.

Mike, in this paragraph, you're hitting on something that has been on
my mind for a while.  We plan to cover this problem in detail in this
talk [1] and we're defining some work for Liberty to better address it
[2][3].  You hit the nail on the head, there is no distinguishing
private and public IP addresses in Neutron currently with IPv6.

Kilo's new subnet pool feature is a start.  It will allow you to
create a shared subnet pool including the /64s from your service
provider.  Tenants can then create a subnet getting an allocation from
it automatically.  However, given the current state of things, there
will be some manual work on the gateway router to route them to the
tenant's router.

Prefix delegation -- which looks on track for Liberty -- is another
option which could fill this void.  It will allow a router to get a
prefix delegation from an external PD system which will be useable on
a tenant subnet.  Presumably the external system will take care of
routing the subnet to the appropriate tenant router.

Carl

[1] http://sched.co/2qdm
[2] https://review.openstack.org/#/c/180267/
[3] https://review.openstack.org/#/c/125401/

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


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

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Following discussion on IRC, a patch is now up to add this config option.
Reviews appreciated.

https://review.openstack.org/#/c/166973/


Cheers,

John




On 23/03/2015 18:11, Carl Baldwin c...@ecbaldwin.net wrote:

On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg)
jodav...@cisco.com wrote:
 The above blueprint outlines an admin-configurable global default pool
to
 be used in the case of a user calling subnet-create without specifying a
 CIDR or subnet-pool ID. If the OpenStack environment has been made
 PD-capable by the operator (a PD-server has been setup), this default
 could be set in such a way to indicate that PD should be used. This
would
 give the user a hassle-free workflow and avoids overloading api
 attributes. It also has the added benefit of not allowing the user to
 request a PD-defined CIDR in an environment that isn¹t PD-capable.

Thank you for bringing up this default.  This was indeed specified in
the BP for this purpose.  However, it is a loose end which we need to
tied up.  It should be easy to add the code to enable setting this
default.  We also need to be sure that our subnet pool code properly
ignores this pool id.

Ping me on IRC and we can coordinate this.

Carl

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

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

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Going forward, I think the best approach for PD would be to align with the
subnet-pools being added by the subnet allocation BP work (thanks to Sean
for bringing this to our attention again).

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-alloca
tion.html#rest-api-impact


The above blueprint outlines an admin-configurable global default pool to
be used in the case of a user calling subnet-create without specifying a
CIDR or subnet-pool ID. If the OpenStack environment has been made
PD-capable by the operator (a PD-server has been setup), this default
could be set in such a way to indicate that PD should be used. This would
give the user a hassle-free workflow and avoids overloading api
attributes. It also has the added benefit of not allowing the user to
request a PD-defined CIDR in an environment that isn¹t PD-capable.

If anyone has any concerns/comments about such an approach I¹d be happy to
hear them. I¹ll be keeping my eye on the subnet allocation patches as they
are merged so we can align our patch as soon as it¹s feasible.

Cheers,

John




On 23/03/2015 15:31, John Belamaric jbelama...@infoblox.com wrote:



On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote:


 My hope is that either the new IPAM subsystem for subnet allocations
would provide this, or that a small API extension could paper over some
of the sharper edges.

In IPAM we have added this concept of a subnet request. The built-in
support would allow you to request any subnet or a specific subnet.
This concept applies to both pool-based and non-pool-based requests.

Currently, a request needs to be essentially encoded in the cidr field
of the subnet creation API call, in order to provide complete API
backwards compatibility. A blank CIDR indicates any subnet; a specific
CIDR indicates to allocate that subnet. However, the intention is that
individual drivers could add their own types of requests. This is
supported in the request factory defined in [1]. This means, for example,
we can implement a request class RFC3633SubnetRequest that handles
acquiring the CIDR via prefix delegation. The user will pass RFC3633 as
the cidr attribute in that case, so that the correct request class is
instantiated. A similar mechanism can be used for address requests - for
example, EUI64 and other auto-generated addresses.

To enable this, an additional change needed beyond [1] is to use the
request factory for validation of the cidr field rather than the API
layer.


[1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py



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


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

Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts

[John Davidge (jodavidg)]

Copying my response on the review below:

Yes that completely makes sense Sean. In our original proposal we wanted
to allow the user to initiate a subnet-create without providing a CIDR,
and have an 'ipv6_pd_enabled' flag which could be set in the API call to
tell Neutron that this particular subnet needs to have its CIDR defined by
PD. The consensus from the community early in the Kilo development cycle
was that changes to the API should be avoided if at all possible, and so
it was agreed that we would use a special ::/64 CIDR for the initial
implementation. In the IPv6 meeting yesterday you mentioned doing this
with an extension rather than modifying the core API. Could you go into
some detail about how you see this extension looking?

Cheers,


John




On 18/03/2015 13:12, Sean M. Collins s...@coreitpro.com wrote:

Hi all,

I recently posted this comment in the review for
https://review.openstack.org/#/c/158697/,
and wanted to post it here so that people can respond. Basically, I have
concerns that I raised during the spec submission process
(https://review.openstack.org/#/c/93054/).

I'm still not totally on board with the proposed user facing API, where
they create a subnet cidr of ::/64, then later it is updated by Neutron
to actually be the cidr that is delegated. My hope is to have a user
facing API that would require little to no user input (since we are
relying on an external system to delegate us a subnet) and Neutron would
create the required constructs internally. My hope is that either the new
IPAM subsystem for subnet allocations would provide this, or that a small
API extension could paper over some of the sharper edges.

Basically, I know we need the user to create a CIDR of ::/64 to satisfy
the Neutron core API's requirement that a subnet MUST have a CIDR when
creating, but I think that in the case of prefix delegation we shouldn't
expose this sharp edge to the user by default.

Does this make sense?

-- 
Sean M. Collins

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


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

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

[John Davidge (jodavidg)]

I am pleased to say that we are now in a good position with this patch.
The necessary DHCPv6 client changes have been made available in the latest
release of Dibbler (1.0.1) and we’re getting some much appreciated
assistance from Ihar and Thomas in having this new version packaged for
wide availability - thanks guys.

We’ve updated the patch to include tests and it's been brought up-to-date
with the latest L3 agent refactoring changes. It is no longer WIP and we
would very much appreciate your reviews and feedback.

https://review.openstack.org/#/c/158697/


Cheers,

John




On 24/02/2015 17:40, John Davidge (jodavidg) jodav...@cisco.com wrote:

Hello all,

We now have a work-in-progress patch up for review:

https://review.openstack.org/#/c/158697/


Feedback on our approach is much appreciated.

Many thanks,

John Davidge
OpenStack@Cisco




On 20/02/2015 18:28, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Those are good news!

I commented on the pull request. Briefly, we can fetch from git, but
would prefer an official release.

Thanks,
/Ihar

On 02/19/2015 11:26 PM, Robert Li (baoli) wrote:
 Hi Kyle, Ihar,
 
 It looks promising to have our patch upstreamed. Please take a look
 at this pull request
 
https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75144912
.
 Most importantly, Tomek asked if it’s sufficient to have the code
 up in his master branch. I guess you guys may be able to help
 answer that question since I’m not familiar with openstack release
 process.
 
 Cheers, Robert
 
 On 2/13/15, 12:16 PM, Kyle Mestery mest...@mestery.com
 mailto:mest...@mestery.com wrote:
 
 On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg)
 jodav...@cisco.com mailto:jodav...@cisco.com wrote:
 
 Hi Ihar,
 
 To answer your questions in order:
 
 1. Yes, you are understanding the intention correctly. Dibbler
 doesn¹t currently support client restart, as doing so causes all
 existing delegated prefixes to be released back to the PD server.
 All subnets belonging to the router would potentially receive a new
 cidr every time a subnet is added/removed.
 
 2. Option 2 cannot be implemented using the current version of
 dibbler, but it can be done using the version we have modified.
 Option 3 could possibly be done with the current version of
 dibbler, but with some major limitations - only one single router
 namespace would be supported.
 
 Once the dibbler changes linked below are reviewed and finalised we
 will only need to merge a single patch into the upstream dibbler
 repo. No further patches are anticipated.
 
 Yes, you are correct that dibbler is not needed unless prefix
 delegation is enabled by the deployer. It is intended as an
 optional feature that can be easily disabled (and probably will be
 by default). A test to check for the correct dibbler version would
 certainly be necessary.
 
 Testing in the gate will be an issue until the new version of
 dibbler is merged and packaged in the various distros. I¹m not sure
 if there is a way to avoid this problem, unless we have devstack
 install from our updated repo while we wait.
 
 To me, this seems like a pretty huge problem. We can't expect
 distributions to package side-changes to upstream projects. The
 correct way to solve this problem is to work to get the changes
 required in the dependent packages upstream into those projects
 first (dibbler, in this case), and then propose the changes into
 Neutron to make use of those changes. I don't see how we can
 proceed with this work until the issues around dibbler has been
 resolved.
 
 
 John Davidge OpenStack@Cisco
 
 
 
 
 On 13/02/2015 16:01, Ihar Hrachyshka ihrac...@redhat.com
 mailto:ihrac...@redhat.com wrote:
 
 Thanks for the write-up! See inline.
 
 On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
 Hi,
 
 while trying to integrate dibbler client with neutron to support
 PD, we countered a few issues with the dibbler client (and
 server). With a neutron router, we have the qg-xxx interface that
 is connected to the public network, on which a dhcp server is
 running on the delegating router. For each subnet with PD
 enabled, a router port will be created in the neutron router. As
 a result, a new PD request will be sent that asks for a prefix
 from the delegating router. Keep in mind that the subnet is added
 into the router dynamically.
 
 We thought about the following options:
 
 1. use a single dibbler client to support the above requirement.
 This means, the client should be able to accept new requests on
 the fly either through configuration reload or other interfaces.
 Unfortunately, dibbler client doesn¹t support it.
 
 Sorry for my ignorance on PD implementation (I will definitely look
 at it the next week), but what does this entry above mean? Do you
 want a single dibbler instance running per router serving all
 subnets plugged into it? And you want to get configuration updates
 when a new subnet is plugged in, or removed from

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

[John Davidge (jodavidg)]

Hello all,

We now have a work-in-progress patch up for review:

https://review.openstack.org/#/c/158697/


Feedback on our approach is much appreciated.

Many thanks,

John Davidge
OpenStack@Cisco




On 20/02/2015 18:28, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Those are good news!

I commented on the pull request. Briefly, we can fetch from git, but
would prefer an official release.

Thanks,
/Ihar

On 02/19/2015 11:26 PM, Robert Li (baoli) wrote:
 Hi Kyle, Ihar,
 
 It looks promising to have our patch upstreamed. Please take a look
 at this pull request
 
https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75144912.
 Most importantly, Tomek asked if it’s sufficient to have the code
 up in his master branch. I guess you guys may be able to help
 answer that question since I’m not familiar with openstack release
 process.
 
 Cheers, Robert
 
 On 2/13/15, 12:16 PM, Kyle Mestery mest...@mestery.com
 mailto:mest...@mestery.com wrote:
 
 On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg)
 jodav...@cisco.com mailto:jodav...@cisco.com wrote:
 
 Hi Ihar,
 
 To answer your questions in order:
 
 1. Yes, you are understanding the intention correctly. Dibbler
 doesn¹t currently support client restart, as doing so causes all
 existing delegated prefixes to be released back to the PD server.
 All subnets belonging to the router would potentially receive a new
 cidr every time a subnet is added/removed.
 
 2. Option 2 cannot be implemented using the current version of
 dibbler, but it can be done using the version we have modified.
 Option 3 could possibly be done with the current version of
 dibbler, but with some major limitations - only one single router
 namespace would be supported.
 
 Once the dibbler changes linked below are reviewed and finalised we
 will only need to merge a single patch into the upstream dibbler
 repo. No further patches are anticipated.
 
 Yes, you are correct that dibbler is not needed unless prefix
 delegation is enabled by the deployer. It is intended as an
 optional feature that can be easily disabled (and probably will be
 by default). A test to check for the correct dibbler version would
 certainly be necessary.
 
 Testing in the gate will be an issue until the new version of
 dibbler is merged and packaged in the various distros. I¹m not sure
 if there is a way to avoid this problem, unless we have devstack
 install from our updated repo while we wait.
 
 To me, this seems like a pretty huge problem. We can't expect
 distributions to package side-changes to upstream projects. The
 correct way to solve this problem is to work to get the changes
 required in the dependent packages upstream into those projects
 first (dibbler, in this case), and then propose the changes into
 Neutron to make use of those changes. I don't see how we can
 proceed with this work until the issues around dibbler has been
 resolved.
 
 
 John Davidge OpenStack@Cisco
 
 
 
 
 On 13/02/2015 16:01, Ihar Hrachyshka ihrac...@redhat.com
 mailto:ihrac...@redhat.com wrote:
 
 Thanks for the write-up! See inline.
 
 On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
 Hi,
 
 while trying to integrate dibbler client with neutron to support
 PD, we countered a few issues with the dibbler client (and
 server). With a neutron router, we have the qg-xxx interface that
 is connected to the public network, on which a dhcp server is
 running on the delegating router. For each subnet with PD
 enabled, a router port will be created in the neutron router. As
 a result, a new PD request will be sent that asks for a prefix
 from the delegating router. Keep in mind that the subnet is added
 into the router dynamically.
 
 We thought about the following options:
 
 1. use a single dibbler client to support the above requirement.
 This means, the client should be able to accept new requests on
 the fly either through configuration reload or other interfaces.
 Unfortunately, dibbler client doesn¹t support it.
 
 Sorry for my ignorance on PD implementation (I will definitely look
 at it the next week), but what does this entry above mean? Do you
 want a single dibbler instance running per router serving all
 subnets plugged into it? And you want to get configuration updates
 when a new subnet is plugged in, or removed from the router?
 
 If that's the case, why not just restarting the client?
 
 2. start a dibbler client per subnet. All of the dibbler clients
 will be using the same outgoing interface (which is the qg-xxx
 interface). Unfortunately, dibbler client uses /etc/dibbler and
 /var/lib/dibbler for its state (in which it saves duid file, pid
 file, and other internal states). This means it can only support
 one client per network node. 3. run a single dibbler client that
 requests a smaller prefix (say /56) and splits it among the
 subnets with PD enabled (neutron subnet requires /64). Depending
 on the neutron router setup, this may result in significant waste

Re: [openstack-dev] [neutron] Prefix delegation using dibbler client

[John Davidge (jodavidg)]

Hi Ihar,

To answer your questions in order:

1. Yes, you are understanding the intention correctly. Dibbler doesn¹t
currently support client restart, as doing so causes all existing
delegated prefixes to be released back to the PD server. All subnets
belonging to the router would potentially receive a new cidr every time a
subnet is added/removed.

2. Option 2 cannot be implemented using the current version of dibbler,
but it can be done using the version we have modified. Option 3 could
possibly be done with the current version of dibbler, but with some major
limitations - only one single router namespace would be supported.

Once the dibbler changes linked below are reviewed and finalised we will
only need to merge a single patch into the upstream dibbler repo. No
further patches are anticipated.

Yes, you are correct that dibbler is not needed unless prefix delegation
is enabled by the deployer. It is intended as an optional feature that can
be easily disabled (and probably will be by default). A test to check for
the correct dibbler version would certainly be necessary.

Testing in the gate will be an issue until the new version of dibbler is
merged and packaged in the various distros. I¹m not sure if there is a way
to avoid this problem, unless we have devstack install from our updated
repo while we wait.

John Davidge
OpenStack@Cisco




On 13/02/2015 16:01, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the write-up! See inline.

On 02/13/2015 04:34 PM, Robert Li (baoli) wrote:
 Hi,
 
 while trying to integrate dibbler client with neutron to support
 PD, we countered a few issues with the dibbler client (and server).
 With a neutron router, we have the qg-xxx interface that is
 connected to the public network, on which a dhcp server is running
 on the delegating router. For each subnet with PD enabled, a router
 port will be created in the neutron router. As a result, a new PD
 request will be sent that asks for a prefix from the delegating
 router. Keep in mind that the subnet is added into the router
 dynamically.
 
 We thought about the following options:
 
 1. use a single dibbler client to support the above requirement.
 This means, the client should be able to accept new requests on the
 fly either through configuration reload or other interfaces.
 Unfortunately, dibbler client doesn¹t support it.

Sorry for my ignorance on PD implementation (I will definitely look at
it the next week), but what does this entry above mean? Do you want a
single dibbler instance running per router serving all subnets plugged
into it? And you want to get configuration updates when a new subnet
is plugged in, or removed from the router?

If that's the case, why not just restarting the client?

 2. start a dibbler client per subnet. All of the dibbler clients
 will be using the same outgoing interface (which is the qg-xxx
 interface). Unfortunately, dibbler client uses /etc/dibbler and
 /var/lib/dibbler for its state (in which it saves duid file, pid
 file, and other internal states). This means it can only support
 one client per network node. 3. run a single dibbler client that
 requests a smaller prefix (say /56) and splits it among the subnets
 with PD enabled (neutron subnet requires /64). Depending on the
 neutron router setup, this may result in significant waste of
 prefixes.

Just to understand all options at the table: can we implement ^^
option with stock dibbler?

 
 Given the significant drawback with 3, we are left with 1 and 2.
 After looking at the dibbler source code, we found that 2 is easier
 to achieve for now by making some small changes in the dibbler
 code. In the long run, we think option 1 is better.
 
 The changes we made to the linux dibbler client code, and the
 dibbler server code can be found in here:
 https://github.com/johndavidge/dibbler/tree/cloud-dibbler.
 Basically it does a few things: ‹ create a unique working area per
 dibbler client ‹ since all the clients use the same outgoing
 interface, we¹d like each dibbler client to use a unique LLA as its
 source address when sending messages. This would avoid clients to
 receive server messages that are not intended for them. ‹ we found
 that dibbler server uses transaction ID alone to identify a match
 between a request and an answer. This would require that unique
 transaction IDs be used among all the existing clients. We found
 that clients could use the same transaction IDs in our
 environment. Therefore, a little change is made in the server code
 so that it will take the request sender into consideration while
 looking up a match.
 
 
 Option 1 requires better understanding of the dibbler code, and we
 think that it may not be possible to make it happen in the kilo
 timeframe. But we think it has significant advantages over option
 2. Regardless, changes made for 2 is also needed since we need to
 run one dibbler client per neutron router.
 
 Now the issue is how to make

[openstack-dev] [Horizon] [UX] Curvature interactive virtual network design

[John Davidge (jodavidg)]

As discussed in the Horizon contributor meet up, here at Cisco we’re interested 
in upstreaming our work on the Curvature dashboard into Horizon. We think that 
it can solve a lot of issues around guidance for new users and generally 
improving the experience of interacting with Neutron. Possibly an alternative 
persona for novice users?

For reference, see:

  1.  http://youtu.be/oFTmHHCn2-g – Video Demo
  2.  
https://www.openstack.org/summit/portland-2013/session-videos/presentation/interactive-visual-orchestration-with-curvature-and-donabe
 – Portland presentation
  3.  https://github.com/CiscoSystems/curvature – original (Rails based) code

We’d like to gauge interest from the community on whether this is something 
people want.

Thanks,

John, Brad  Sam

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Heat] HOT Software orchestration proposal for workflows

[John Davidge -X (jodavidg - AAP3 INC at Cisco)]

It looks like this discussion involves many of the issues faced when
developing the Curvature  Donabe frameworks, which were presented at the
Portland Summit - slides and video here:

http://www.openstack.org/summit/portland-2013/session-videos/presentation/i
nteractive-visual-orchestration-with-curvature-and-donabe

Much of the work on the Donabe side revolved around defining a simple
JSON-based API for describing the sorts of virtual application templates
being discussed. All of the code for both Curvature and Donabe has
recently been made open source and is available here:

http://ciscosystems.github.io/curvature/

http://ciscosystems.github.io/donabe/

It looks like some of the ground covered by these projects can be helpful
to this discussion.

John Davidge
jodav...@cisco.com



-- Forwarded message --
From: Thomas Spatzier thomas.spatz...@de.ibm.com
Date: Wed, Oct 9, 2013 at 12:40 AM
Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
proposal for workflows
To: OpenStack Development Mailing List openstack-dev@lists.openstack.org


Excerpts from Clint Byrum's message

 From: Clint Byrum cl...@fewbar.com
 To: openstack-dev openstack-dev@lists.openstack.org,
 Date: 09.10.2013 03:54
 Subject: Re: [openstack-dev] [Heat] HOT Software orchestration
 proposal for workflows

 Excerpts from Stan Lagun's message of 2013-10-08 13:53:45 -0700:
  Hello,
 
 
  That is why it is necessary to have some central coordination service
which
  would handle deployment workflow and perform specific actions (create
VMs
  and other OpenStack resources, do something on that VM) on each stage
  according to that workflow. We think that Heat is the best place for
such
  service.
 

 I'm not so sure. Heat is part of the Orchestration program, not
workflow.


I agree. HOT so far was thought to be a format for describing templates in
a structural, declaritive way. Adding workflows would stretch it quite a
bit. Maybe we should see what aspects make sense to be added to HOT, and
then how to do workflow like orchestration in a layer on top.

  Our idea is to extend HOT DSL by adding  workflow definition
capabilities
  as an explicit list of resources, components¹ states and actions.
States
  may depend on each other so that you can reach state X only after
you¹ve
  reached states Y and Z that the X depends on. The goal is from initial
  state to reach some final state ³Deployed².
 

We also would like to add some mechanisms to HOT for declaratively doing
software component orchestration in Heat, e.g. saying that one component
depends on another one, or needs input from another one once it has been
deployed etc. (I BTW started to write a wiki page, which is admittedly far
from complete, but I would be happy to work on it with interested folks -
https://wiki.openstack.org/wiki/Heat/Software-Configuration-Provider).
However, we must be careful not to make such features too complicated so
nobody will be able to use it any more. That said, I believe we could make
HOT cover some levels of complexity, but not all. And then maybe workflow
based orchestration on top is needed.


 Orchestration is not workflow, and HOT is an orchestration templating
 language, not a workflow language. Extending it would just complect two
 very different (though certainly related) tasks.

 I think the appropriate thing to do is actually to join up with the
 TaskFlow project and consider building it into a workflow service or
tools
 (it is just a library right now).

  There is such state graph for each of our deployment entities
(service,
  VMs, other things). There is also an action that must be performed on
each
  state.

 Heat does its own translation of the orchestration template into a
 workflow right now, but we have already discussed using TaskFlow to
 break up the orchestration graph into distributable jobs. As we get more
 sophisticated on updates (rolling/canary for instance) we'll need to
 be able to reason about the process without having to glue all the
 pieces together.

  We propose to extend HOT DSL with workflow definition capabilities
where
  you can describe step by step instruction to install service and
properly
  handle errors on each step.
 
  We already have an experience in implementation of the DSL, workflow
  description and processing mechanism for complex deployments and
believe
  we¹ll all benefit by re-using this experience and existing code,
having
  properly discussed and agreed on abstraction layers and distribution
of
  responsibilities between OS components. There is an idea of
implementing
  part of workflow processing mechanism as a part of Convection
proposal,
  which would allow other OS projects to benefit by using this.
 
  We would like to discuss if such design could become a part of future
Heat
  version as well as other possible contributions from Murano team.
 

 Thanks really for thinking this through. Windows servers are not unique
in
 this regard. Puppet and chef are pretty decent