[openstack-dev] [Openstack-operators][neutron][fwaas] Removing FWaaS V1 in Stein

[German Eichberger]

All,



With the Stein release we will remove support for FWaaS V1 [1]. It has been 
marked deprecated since Liberty (2015)  and was an experimental API. It is 
being replaced with FWaaS V2 [2] which has been available since the Newton 
release.


What is Neutron FWaaS?

Firewall-as-a-Service is a neutron project which provides router (L3) and port 
(L2) firewalls to protect networks and vms. [3]


What is Neutron FWaaS V1?

FWaaS V1 was the first implementation of Firewall-as-a-Service and focused on 
the router port. This implementation has been ported to FWaaS V2.


What is FWaaS V2?

FWaaS V2 extends Firewall-as-a-Service to any neutron port - thus offering the 
same functionality as Security Groups but with a richer API (e.g. deny/reject 
traffic).


Why is FWaaS V1 being removed?

FWaaS V1 has been deprecated since 2015 and with FWaaS V2 being released for 
several cycles it is time to remove FWaaS V1.


How do I migrate?

Existing firewall policies and rules need to be recreated with FWaaS V2. At 
this point we don’t offer an automated migration tool.


[1] 
https://developer.openstack.org/api-ref/network/v2/#fwaas-v1-0-deprecated-fw-firewalls-firewall-policies-firewall-rules


[2] 
https://developer.openstack.org/api-ref/network/v2/#fwaas-v2-0-current-fwaas-firewall-groups-firewall-policies-firewall-rules


[3] https://www.youtube.com/watch?v=9Wkym4BeM4M


__
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] [octavia] Proposing Carlos Goncalves (cgoncalves) as an Octavia core reviewer

[German Eichberger]

Concur. Carlos has been a great contributor!

+1

From: Nir Magnezi 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, August 31, 2018 at 5:02 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [octavia] Proposing Carlos Goncalves (cgoncalves) 
as an Octavia core reviewer

Carlos made a significant impact with quality reviews and code contributions.
I think he would make a great addition to the core team.

+1 From me.

/Nir

On Fri, Aug 31, 2018 at 6:29 AM Jacky Hu 
mailto:huda...@hotmail.com>> wrote:
+1
Definitely a good contributor for the octavia community.

发自我的 iPhone

> 在 2018年8月31日，上午11:24，Michael Johnson 
> mailto:johnso...@gmail.com>> 写道：
>
> Hello Octavia community,
>
> I would like to propose Carlos Goncalves as a core reviewer on the
> Octavia project.
>
> Carlos has provided numerous enhancements to the Octavia project,
> including setting up the grenade gate for Octavia upgrade testing.
>
> Over the last few releases he has also been providing quality reviews,
> in line with the other core reviewers [1]. I feel that Carlos would
> make an excellent addition to the Octavia core reviewer team.
>
> Existing Octavia core reviewers, please reply to this email with your
> support or concerns with adding Jacky to the core team.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
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] [octavia] Proposing Jacky Hu (dayou) as an Octavia core reviewer

[German Eichberger]

+1

Really excited to work with Jacky --

German

On 3/26/18, 8:33 PM, "Michael Johnson"  wrote:

Hello Octavia community,

I would like to propose Jacky Hu (dayou) as a core reviewer on the
Octavia project.

Jacky has done amazing work on Octavia dashboard, specifically
updating the look and feel of our details pages to be more user
friendly.  Recently he has contributed support for L7 policies in the
dashboard and caught us up with the wider Horizon framework advances.

Jacky has also contributed thoughtful reviews on the main Octavia
project as well as contributed to the L3 Active/Active work in
progress.

Jacky's review statistics are in line with the other core reviewers
[1] and I feel Jacky would make a great addition to the Octavia core
reviewer team.

Existing Octavia core reviewers, please reply to this email with your
support or concerns with adding Jacky to the core team.

Michael

[1] http://stackalytics.com/report/contribution/octavia-group/90

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


__
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][fwaas] YouTube video demoing FWaaS V2 L2

[German Eichberger]

All,

With great pleasure I am sharing this link of  Chandan’s excellent video 
showing the new L2 functionality: 
https://www.youtube.com/watch?v=gBYJIZ4tUaw=youtu.be

Psyched and many thanks to Chandan --

German

__
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

[German Eichberger]

Hi,

Thanks for all the help and support over the years. Both LBaaS (Octavia)  and 
FWaaS wouldn’t be what they are today without your leadership and advice –

All the best + good luck,
German

From: "Armando M." 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 15, 2017 at 8:04 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

Hi neutrinos,

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

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

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

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

Cheers,
Armando

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

Re: [openstack-dev] [all] Switching to longer development cycles

[German Eichberger]

It looks like the implicit expectation is that devs also need to attend the 
Forums at the summit in addition to the PTG. The Forums, though important, 
hardly made it worthwhile for me to attend the summit (and in fact I skipped 
Sydney). On the other hand some devs got together and hashed out some plans for 
their projects. Personally, I feel the PTG is not working if we also have 
summits – and having two summits and one PTG will make things worse. Therefore 
I propose to scrap the PTG and add “design summits” back to the OpenStack 
summit. As a side effect this will be a better on-ramp for casual developers 
who can’t justify going to the PTG and ensure enough developers are on-hand to 
hear the operator’s feedback.

German

From: Tim Bell 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, December 13, 2017 at 10:15 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [all] Switching to longer development cycles

The forums would seem to provide a good opportunity for get togethers during 
the release cycle. With these happening April/May and October/November, there 
could be a good chance for productive team discussions and the opportunities to 
interact with the user/operator community.

There is a risk that deployment to production is delayed, and therefore 
feedback is delayed and the wait for the ‘initial bug fixes before we deploy to 
prod’ gets longer.

If there is consensus, I’d suggest to get feedback from openstack-operators on 
the idea. My initial suspicion is that it would be welcomed, especially by 
those running from distros, but there are many different perspectives.

Tim

From: Amy Marrich 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, 13 December 2017 at 18:58
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [all] Switching to longer development cycles

I think Sean has made some really good points with the PTG setting things off 
in the start of the year and conversations carrying over to the Forums and 
their importance. And having a gap at the end of the year as Jay mentioned will 
give time for those still about to do finishing work if needed and if it's 
planned for in the individual projects they can have an earlier 'end' to allow 
for members not being around.

The one year release would help to get 'new' users to adopt a more recent 
release, even if it's the one from the year previously as there is the 
'confidence' that it's been around for a bit and been used by others in 
production. And if projects want to do incrementals they can, if I've read the 
thread correctly. Also those that want the latest will just use master anyways 
as some do currently.

With the move to a yearly cycle I agree with the 1 year cycle for PTLs, though 
if needed perhaps a way to have a co-PTL or a LT could be implemented to help 
with the longer duties?

My 2 cents from the peanut gallery:)

Amy (spotz)

On Wed, Dec 13, 2017 at 11:29 AM, Sean McGinnis 
> wrote:
On Wed, Dec 13, 2017 at 05:16:35PM +, Chris Jones wrote:
> Hey
>
> On 13 December 2017 at 17:12, Jimmy McArthur 
> > wrote:
>
> > Thierry Carrez wrote:
> >
> >> - It doesn't mean that teams can only meet in-person once a year.
> >> Summits would still provide a venue for team members to have an
> >> in-person meeting. I also expect a revival of the team-organized
> >> midcycles to replace the second PTG for teams that need or want to meet
> >> more often.
> >>
> > The PTG seems to allow greater coordination between groups. I worry that
> > going back to an optional mid-cycle would reduce this cross-collaboration,
> > while also reducing project face-to-face time.
>
>
> I can't speak for the Foundation, but I would think it would be good to
> have an official PTG in the middle of the cycle (perhaps neatly aligned
> with some kind of milestone/event) that lets people discuss plans for
> finishing off the release, and early work they want to get started on for
> the subsequent release). The problem with team-organised midcycles (as I'm
> sure everyone remembers), is that there's little/no opportunity for
> cross-project work.
>
> --
> Cheers,
>
> Chris
This was one of my concerns initially too. We may have to see how things go and
course correct once we have a little more data to go on. But the thought (or at
least the hope) was that we could get by with using the one PTG early in the
cycle to get alignment, then though IRC, the mailing list, and the Forums (keep
in mind there will be two Forums within the cycle) we would be able to keep
things going and discuss any cross project 

Re: [openstack-dev] [neutron][lbaasv2][agent implementation] L7 policy support

[German Eichberger]

Mihaela,

The first version with L7 was Newton and beginning then the LBaaS V2 namespace 
driver would support it as well as Octavia.

German

From: "mihaela.ba...@orange.com" 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, October 3, 2017 at 2:13 AM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [neutron][lbaasv2][agent implementation] L7 policy 
support

Hello,

Does the agent implementation of LBaaSv2 support L7 policies? I am testing with 
Mitaka version and I get “Not Implemented Error”.

{"asctime": "2017-10-03 07:34:42.764","process": "18","levelname": 
"INFO","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"Calling driver operation 
NotImplementedManager.create"}
{"asctime": "2017-10-03 07:34:42.765","process": "18","levelname": 
"ERROR","name": "neutron_lbaas.services.loadbalancer.plugin", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"There was an error in the 
driver"}
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>Traceback (most recent call last):
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>  File 
"/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/services/loadbalancer/plugin.py",
 line 486, in _call_driver_operation
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>driver_method(context, db_entity)
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>  File 
"/opt/neutron/lib/python2.7/site-packages/neutron_lbaas/drivers/driver_base.py",
 line 36, in create
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>raise NotImplementedError()
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>NotImplementedError
2017-10-03 07:34:42.765 18 TRACE neutron_lbaas.services.loadbalancer.plugin  
>
{"asctime": "2017-10-03 07:34:42.800","process": "18","levelname": 
"ERROR","name": "neutron.api.v2.resource", "request_id": 
"req-186bf812-1cdf-496b-a117-711f1e42c6bd", "user_identity": {"user_id": 
"44364a07de754daa9ffeb2911fe3620a", "project_id": 
"a5f15235c0714365b98a50a11ec956e7", "domain_id": "-", "user_domain_id": "-", 
"project_domain_id": "-"},"instance": {},"message":"create failed"}
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >Traceback (most 
recent call last):
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 84, 
in resource
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >result = 
method(request=request, **args)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 410, in 
create
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >return 
self._create(request, body, **kwargs)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_db/api.py", line 148, in wrapper
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >ectxt.value 
= e.inner_exc
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in 
__exit__
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >
self.force_reraise()
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >
six.reraise(self.type_, self.value, self.tb)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/oslo_db/api.py", line 138, in wrapper
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >return 
f(*args, **kwargs)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 521, in 
_create
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >obj = 
do_create(body)
2017-10-03 07:34:42.800 18 TRACE neutron.api.v2.resource  >  File 
"/opt/neutron/lib/python2.7/site-packages/neutron/api/v2/base.py", line 503, in 

Re: [openstack-dev] [octavia] Proposing Nir Magnezi as Octavia core reviewer

[German Eichberger]

+1

Welcome Nir, well earned.

German

On 10/4/17, 4:28 PM, "Michael Johnson"  wrote:

Hello OpenStack folks,

I would like to propose Nir Magnezi as a core reviewer on the Octavia 
project.

He has been an active contributor to the Octavia projects for a few
releases and has been providing solid patch review comments. His
review stats are also in line with other core reviewers.

Octavia cores, please reply to this e-mail with your
agreement/disagreement to this proposal.

Michael

__
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] [tc][election] Questions for Candidates

[German Eichberger]

-What is one trait you have that makes it difficult to work in groups like the 
TC and how do you counteract it?
I am probably overly fascinated by new technology and would be the first to 
re-invent the wheel. I am probably in good company with that at the TC but I 
have internalized the lean startup mantra and started asking even if the 
technology is shiny does it really help our users? Does it enable new features? 
Does it take care of some tech debt?

- What do you see as the biggest roadblock in the upcoming releases for the TC?
I have seen budgets and priorities shift for companies sponsoring work on 
OpenStack. I see this as the biggest road block and as a community we need to 
do a better job to attract contributors and sponsors.

-What is your favorite thing about OpenStack?
The people. I have never met nicer and more dedicated people then the 
developers in OpenStack. This is also a main reason for running to give back 
and help them.

German

From: Kendall Nelson 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, April 12, 2017 at 12:19 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][election] Questions for Candidates

Hello Candidates!

You all have proven yourselves to be crucial parts of the community and I just 
wanted to say good luck to each one of you in the upcoming election!

Also though, I thought it might be good to ask a few more questions. It's easy 
to talk about what you all want to champion on the TC and about the ideal 
breakdown of how you want to spend your time, but it's much harder to answer 
questions that might highlight some of the daily struggles. So! Interview time:

-What is one trait you have that makes it difficult to work in groups like the 
TC and how do you counteract it?

- What do you see as the biggest roadblock in the upcoming releases for the TC?
And one lighthearted question:

-What is your favorite thing about OpenStack?

Thank you for your answers!

-Kendall Nelson
__
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] [tc] [elections] Available time and top priority

[German Eichberger]

I have read very good ideas in this thread but I somehow can’t shake the 
feeling that people who are quite comfortable with the irc meeting are looking 
for a solution for people who are not.  So, before we do any changes I would 
send out a survey and see what the developers we are serving actually want. 

In my experience interacting with the TC it has always been tough to get in 
touch with people and I will therefore institute (at least for me) office hours 
where you can interact with me each week and bring me your issues. 

To close, the other day I was listening to somebody describing how she picked 
mentors. Not being a native English speaker she picked her mentors based on if 
they would speak in her native language with her. This really drives home the 
point about diversity and how important it is to recruit and sponsor people 
from different backgrounds for the TC. 

Thanks,
German

On 4/12/17, 7:30 AM, "Flavio Percoco"  wrote:

On 12/04/17 11:07 +0200, Thierry Carrez wrote:
>Ildiko Vancsa wrote:
>>> On 2017. Apr 12., at 3:18, Monty Taylor >> > wrote:
>>> [...]
>>> Email allows someone to compose an actual structured narrative, and
>>> for replies to do the same. Some of us are loquatious and I imagine
>>> can be hard to follow even with time to read.
>>>
>>> IRC allows someone to respond quickly, and for someone to be like "yo,
>>> totes sorry, I didn't mean that at all LOL" and to walk things back
>>> before a pile of people become mortally insulted.
>>>
>>> Like now - hopefully you'll give me a smiley in IRC ... but you might
>>> not, and I'm stuck worrying that my tone came across wrong. Then if
>>> you just don't respond because ZOMG-EMAIL, I might start day drinking.
>>
>> Big +1 on balance.
>>
>> I agree in general that we need to revisit how to be more inclusive and
>> how to provide as equal conditions to people all around the globe as
>> possible.
>>
>> That said I still would like to keep the ability to have allocated time
>> for synchronous communication and allow the TC to be more of a team as
>> opposed to a group of people driving their own and some shared missions.
>> I think it helps with seeing maybe different parts but still the same
>> big picture and making the group more efficient with decision making and
>> bringing the community forward.
>> [...]
>
>Agree with you Ildiko and Monty, we still need sync communication to get
>a better feel of everyone's feelings on a particular issue, especially
>on complex issues. At the same time, a unique weekly meeting is actively
>preventing people from participating. It is also very active and noisy,
>the timebox can be painful, and its weekly cadence makes a good reason
>for procrastinating in reviews until the topic is raised in meeting,
>where final decision is made. Creating multiple official meetings
>spreads the pain instead of eliminating it. It makes it easier for more
>people to join, but more difficult for any given member to participate
>to every meeting. Our ability to quickly process changes might be affected.
>
>One idea I've been considering is eliminating the one and only sacred
>one-hour weekly TC meeting, and encouraging ad-hoc discussions (on
>#openstack-dev for example) between change proposers and smaller groups
>of TC members present in the same timezone. That would give us a good
>feel of what everyone thinks, reduce noise, and happen at various times
>during the day on a public forum, giving an opportunity for more people
>to jump in the discussion. The informal nature of those discussions
>would make the governance reviews the clear focal point for coordination
>and final decision.
>
>It's clearly not the perfect silver bullet though, so I'd very much like
>to hear other ideas :)


I believe I shared this with you on one of our conversations over dinner one
night. I'm glad to see you're more convinced now. I've talked about this 
with
you and other folks among the TC and I'm growing more convinced that it's 
the
right thing to do.

I've toyed with this idea for a bit already and I also mentioned it in my 
reply
to Matt[0] yesterday. As I mentioned in my email, I believe most can be 
achieved
on gerrit and we can instead focus on having a better way for ad-hoc
conversations and mentoring of people that need support from the TC.

[0] 
http://lists.openstack.org/pipermail/openstack-dev/2017-April/115255.html

Flavio

-- 
@flaper87
Flavio Percoco


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

Re: [openstack-dev] [tc][elections]questions about one platform vision

[German Eichberger]

Hi,

Though I haven’t attended the operator summit in person a them which has been 
mentioned to me is that we need to offer better reference architectures. I use 
the plural here on purpose because I don’t think there will be one 
architecture/combination of projects which works for everybody. As a community 
(and the TC can help) we should write up guides for reference architectures for 
containers, vms, and bare metal. But we  don’t need to offer just one project – 
there are a couple of ways to get there and we should offer choice. But we owe 
it to the operators that we have tested whatever we write up at some scale.

The second meaning for a “one platform” vision would be a unified API for 
Containers, VMs, and bare metal. I have talked to several people who would like 
to write software which doesn’t need to distinguish between different APIs to 
accomplish that. But I still feel that we should adhere to the Unix philosophy 
and make the best API for each technology and then have the orchestration 
platform or higher level abstractions (e.g. cloud native) worry about it.

This leads me to one of my gripes with the way we work. We sort of accepted 
that it is the projects responsibility to write tests and documentation but 
when it comes who is writing the Heat integration, the Open Stack Ansible part, 
or the Gophercloud part – things get real murky. I don’t iike to add another 
burden to some of the small projects but we also need to figure out a way that 
those things are current and compete. I am hoping that having reference 
architectures can guide us in this regard and I think we need to add more 
visibility what those solution supports and where the gaps are.

Thanks,
German


From: joehuang 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Tuesday, April 11, 2017 at 10:54 PM
To: openstack-dev 
Subject: [openstack-dev] [tc][elections]questions about one platform vision

Hello,

I heard the one platform vision in OpenStack now and then: One platform for 
virtual machines, containers and bare metal.

I also learned that there are some groups working on making Kubernets being 
able to manage virtual machines. Except running containers in virtual machine, 
there is also the need for running containers in bare metal.

There are several projects connecting OpenStack to container world: Zun, 
Magnum, Kuryr, Fuxi... Projects to deal with bare metal like Ironic, Morgan, ...

Can all these efforts lead us to one platform vision? We have to think over the 
question.

What's the one platform will be in your own words? What's your proposal and 
your focus to help one platform vision being achieved?


Best Regards
Chaoyi Huang (joehuang)
__
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] [tc] [elections] Available time and top priority

[German Eichberger]

Agreed but not only for the TC. I also heard privately from some contributors 
that meetings times prevent them from fully engage with a project. This is 
something where we as the TC can lead by example.

German

On 4/10/17, 3:06 PM, "Davanum Srinivas"  wrote:

Matt,

I second this request. At least one person i talked to, pointed this
as a primary reason for not standing for the TC election.

Thanks,
Dims

On Mon, Apr 10, 2017 at 2:52 PM, Matt Riedemann  wrote:
> On 4/10/2017 1:18 PM, Chris Dent wrote:
>>
>> On Mon, 10 Apr 2017, Thierry Carrez wrote:
>>
>>> So my question is the following: if elected, how much time do you think
>>> you'll be able to dedicate to Technical Committee affairs (reviewing
>>> proposed changes and pushing your own) ?
>>
>>
>> I've been regularly reviewing changes in the governance repo and
>> attending the weekly TC meeting for well over a year now. Increasing
>> that commitment to include shepherding new initiatives, either ones
>> I start myself or work on in concert with others, is why I'm running
>> for the TC and I wouldn't be doing so if I didn't think I had the
>> time and energy to support that.
>>
>> Making a specific prediction on how much time that will take is
>> challenging; some weeks will take more time than others. I intend to
>> do what's needed to do the job well.
>>
>>> If there was ONE thing, one
>>> initiative, one change you will actively push in the six months between
>>> this election round and the next, what would it be ?
>>
>>
>> Just ONE initiative is difficult because from my perspective what
>> matters is that whatever initiatives happen to be in progress, they
>> are transparent, inclusive and actually make some kind of
>> difference. But since ONE is the request:
>>
>> My hallmark complaint with the TC since I was first aware of it has
>> been that, often, resolutions or plans can emerge from the TC so
>> late in their development that engaging them in a way that allows
>> consideration of completely different options is hard. Hard for a
>> variety of reasons; one is that it can feel a bit rude to criticize
>> a complete seeming idea that someone clearly put a lot of effort
>> into. This means discussion proceeds as an evaluation of the
>> proposal rather than as analysis of the root causes of the problems
>> to be solved or the full consequences of the goals being described.
>>
>> This situation has improved over the years, I think there is at
>> least increased awareness, and some concrete efforts to allow people
>> to be involved, but we can do more to make it easier and lighter.
>>
>> I would prefer that the TC's constituency was more actively made
>> aware of pending work and ongoing debates prior to the creation of
>> resolutions (even if WIP) in gerrit or having big sessions at the
>> Forum.  One way to do this would be to follow the growing trend of
>> weekly newsletters and updates and do one for the TC. I recall this
>> was tried (in the form of blog posts, and to some extent in response
>> to my prompting) a while back, but didn't really take off. I
>> wonder if that format was too heavyweight?
>>
>> I'm proud of having played a part in the newsletter trend and I
>> think the results for the API-WG and the placement project have been
>> very positive. Doing something similar for the TC -- in a
>> lightweight, just-the-highlights kind of way -- is something I could
>> do (I hope with the occasional help of the rest of the TC) and is
>> something I think would be useful. With luck the newsletter would
>> operate as a catalyst around which casual discussion and idea
>> sharing would accrete.
>>
>> What I hope would happen as a result is that people would feel more
>> aware of and able to participate in the discussion and processes
>> working to shape the future of OpenStack.
>>
>>
>>
>> 
__
>> 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
>>
>
> Thanks Chris. This reminded me of something I wanted to ask about, to all 
TC
> members, or those running for a seat.
>
> Lots of projects have alternating meeting times to accommodate 
contributors
> in different time zones, especially Europe and Asia.
>
> The weekly TC meeting, however, does not.
>
> I have to assume this has come up before and if so, why hasn't the TC
> adopted an alternating meeting schedule?
>
> For example, it's 4am in Beijing when 

Re: [openstack-dev] [tc] [elections] Available time and top priority

[German Eichberger]

Hi,

I am well aware that being on the TC is a serious time commitment and that 
there is more to do than a given day has hours. So I read your question more 
about prioritizing and how I would do that. A fair part of how I prioritize 
depends on input from others. That’s why I said listening to operators, 
developers, and end users is key. This will inform where I will try to spend my 
time. As for my big initiative, I want to push my heart is with small or 
underfunded projects and making life easier for them. I don’t think this can be 
done with one big thing but rather small steps like better mentoring, 
documentation,  better visibility by inviting them to say the Forum in Boston, 
but first and foremost helping them to have a voice at the TC.  

Thanks,
German

On 4/10/17, 5:16 AM, "Thierry Carrez"  wrote:

Hi everyone,

New in this TC election round, we have a few days between nominations
and actual voting to ask questions and get to know the candidates a bit
better. I'd like to kick off this new "campaigning period" with a basic
question on available time and top priority.

All the candidates are top community members with a lot of
responsibilities on their shoulders already. My experience tells me that
it is easy to overestimate the time we can dedicate to Technical
Committee matters, and how much we can push and get done in six months
or one year. At the same time, our most efficient way to make progress
is always when someone "owns" a particular initiative and pushes it
through the governance process.

So my question is the following: if elected, how much time do you think
you'll be able to dedicate to Technical Committee affairs (reviewing
proposed changes and pushing your own) ? If there was ONE thing, one
initiative, one change you will actively push in the six months between
this election round and the next, what would it be ?

Thanks in advance for your answers !

-- 
Thierry Carrez (ttx)

__
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][lbaasv2] Migrate LBaaS instance

[German Eichberger]

Hi Saverio,

We completely understand that operators are still on older versions of 
OpenStack and we are executing against the  OpenStack release series
[1] and we adhere to the support phases as outlined in [2]. So any new features 
will only be added to Pike whereas bug fixes will be carried back right now 
Ocata and Newton will only see Security Patches. If this doesn’t meet your 
needs I would encourage you to get those guidelines changed. We also frequently 
seek input from operators on new features and/or pain points. I am curious what 
the use case is for a non-scalable/non-HA load balancer like the 
namespace/haproxy driver in production.

Us deprecating LBaaS V2 won’t relieve us from our obligation to provide bug 
fixes and security fixes to the previous versions - furthermore we learned from 
the LBaaS V1 migration and we are committed to providing migration scripts for 
Octavia and potentially the namespace driver. We might need to do a better job 
articulating our migration strategy. 

Thanks,
German

[1] https://releases.openstack.org
[2] https://docs.openstack.org/project-team-guide/stable-branches.html

On 3/17/17, 7:54 AM, "Saverio Proto"  wrote:

Hello there,

I am just back from the Ops Midcycle where Heidi Joy Tretheway reported
some data from the user survey.

So if we look at deployments with more than 100 servers NO ONE IS USING
NEWTON yet. And I scream this loud. Everyone is still in Liberty or Mitaka.

I am just struggling to upgrade to LBaaSv2 to hear that is already going
into deprecation. The feature Zhi is proposing is important also for me
once I go to production.

I would encourage devs to listen more to operators feedback. Also you
devs cant just ignore that users are running still Liberty/Mitaka so you
need to change something in this way of working or all the users will
run away.

thank you

Saverio


On 16/03/17 16:26, Kosnik, Lubosz wrote:
> Hello Zhi,
> Just one small information. Yesterday on Octavia weekly meeting we
> decided that we’re gonna add new features to LBaaSv2 till Pike-1 so the
> windows is very small.
> This decision was made as LBaaSv2 is currently Octavia delivery, not
> Neutron anymore and this project is going into deprecations stage.
> 
> Cheers,
> Lubosz
> 
>> On Mar 16, 2017, at 5:39 AM, zhi > > wrote:
>>
>> Hi, all
>> Currently, LBaaS v2 doesn't support migration. Just like router
>> instances, we can remove a router instance from one L3 agent and add
>> it to another L3 agent.
>>
>> So, there is a single point failure in LBaaS agent. As far as I know,
>> LBaaS supports " allow_automatic_lbaas_agent_failover ". But in many
>> cases, we want to migrate LBaaS instances manually. Do we plan to do 
this?
>>
>> I'm doing this right now. But I meet a question. I define a function
>> in agent_scheduler.py like this:
>>
>> def remove_loadbalancer_from_lbaas_agent(self, context, agent_id,
>> loadbalancer_id):
>> self._unschedule_loadbalancer(context, loadbalancer_id, agent_id)
>>
>> The question is, how do I notify LBaaS agent? 
>>
>> Hope for your reply.
>>
>>
>>
>> Thanks
>> Zhi Chang
>> 
__
>> 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
> 


-- 
SWITCH
Saverio Proto, Peta Solutions
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 1573
saverio.pr...@switch.ch, http://www.switch.ch

http://www.switch.ch/stories

__
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] [ansible]Octavia ansible script

[German Eichberger]

You will also need the related Neutron and ansible patch to run it.

Please keep me posted –

German

From: Michael Johnson <johnso...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Tuesday, February 28, 2017 at 11:54 AM
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ansible]Octavia ansible script

Hi Santhosh,

The correct path to the git repo is: 
http://git.openstack.org/cgit/openstack/openstack-ansible-os_octavia/

Though at this point the code has not merged, so you will need to pull from the 
patch if you want to try it out:
https://review.openstack.org/#/c/417210/

Michael


From: Santhosh Fernandes [mailto:santhosh.fernan...@gmail.com]
Sent: Monday, February 27, 2017 7:15 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [ansible]Octavia ansible script

Thanks Major Hayden,

Hello German,

I don't have access to repo 
git://git.openstack.org/openstack/openstack-ansible-os_octavia<http://git.openstack.org/openstack/openstack-ansible-os_octavia>

Can you provide us access ?

Thanks,
Santhosh







On Tue, Feb 7, 2017 at 7:37 PM, Major Hayden 
<major.hay...@rackspace.com<mailto:major.hay...@rackspace.com>> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 02/07/2017 12:00 AM, Santhosh Fernandes wrote:
> Can we know the status of octavia ansible script ?
>
> Link :- https://blueprints.launchpad.net/~german-eichberger 
> <https://blueprints.launchpad.net/%7Egerman-eichberger>
>
> Is there any version available for beta testing. Can you provide us link? or 
> time line of availability.

Hello Santosh,

Although I drafted the spec[0], German Eichberger has taken over the work on 
the WIP patchset[1].  He would be the best person to discuss timelines and 
remaining work to be done.

[0] 
http://specs.openstack.org/openstack/openstack-ansible-specs/specs/mitaka/lbaasv2.html
[1] https://review.openstack.org/#/c/417210/

- --
Major Hayden
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJYmdSOAAoJEHNwUeDBAR+xkh0P/25yqkYIIxPuO/uvV+jNdiny
NMxNClMfNxpKagCjokJyoMvyVDVX0VR71RloEeigOrTGTP7goAotn99J0pUK+je/
X7zU7POwqV92mAj/3gU7uWm1792EZNCWNpnd9IQiik9PfEcLPmmW1FZeuxyY/l8K
ZE3VOAId0lHaZYbHXR9GCLzy5QwwXM1kg1+Ub1ivIbU3Q81Ais3L64KXLth7ahtu
5dIaCAKZ6uqOVRe336kI9aYPv5N4Fpwt5OkZUdGf4iNc/fivAjrGxaLt9H0ldZJQ
lsbOl1wtjlYJwreQWVGaNBEx/F1UZocnnvzUe9vAUIY2leTZ4eQck16fEkbkRe6b
Zl+o/GVh0mwS+IBjZcilJxQ7PoOX/07Z2wZOHuy8ihUIkM/L2ySP3TBWImv5a5H0
eQW1uK1B45j68E61oEuyW9DvNCWNTltUwD/FQNk833vFAtv35eqMRF1vhx3pPwmO
GI1SQC55n0q96DF+5JedkAVy3qXwgt4CQwxvku8meD0hFb7XpWwy5DBd5p4ZbBb4
XpjlsGkLzBK0uyLPyXaZ0LbFJ3Czp68Gbys09yLxjGI+P+PFWuWGVgoL/+FV9XA2
H7St0aFZJgM0cLFYYQF1ols48SbPUp3HchexaXgltMfGYy2A3x/nnbEJSPtH7Vp9
V9TEomffspXHgMQ2U3R5
=BmgA
-END PGP SIGNATURE-

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

__
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

[German Eichberger]

+1

Sent from my iPhone

On Feb 17, 2017, at 5:43 PM, Michael Johnson 
> wrote:

+1

Thanks for setting this up,

Michael

From: Kevin Benton [mailto:ke...@benton.pub]
Sent: Friday, February 17, 2017 11:19 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

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

[openstack-dev] [Neutron][FWaaS][PTG] FWaaS team gathering Thursday for lunch

[German Eichberger]

All,

The FWaaS team will meet for lunch at the Sheraton tomorrow, Thursday, to tlak 
about Pike priorities (https://etherpad.openstack.org/p/fwaas-pike) and prepare 
for Friday’s Advanced Srrvices session. Ping us on irc if you can’t find our 
table.

German
__
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-lbaas][barbican][octavia]certs don't get deregistered in barbican after lbaas listener delete

[German Eichberger]

Hi,

The idea was that we would like to let the user know in Barbican when the 
certificate is being used with LBaaS. Therefore, we added the register and 
de-register logic. I don’t know of any use case where a certificate needs to be 
deleted in Barbican when LBaaS doesn’t need it any longer.

So I agree with Andrey – it’s the same semantic as images.

German

From: Andrey Grebennikov 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, January 27, 2017 at 12:07 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Cc: Subrahmanyam Ongole 
Subject: Re: [openstack-dev] [neutron-lbaas][barbican][octavia]certs don't get 
deregistered in barbican after lbaas listener delete

Frankie,

What is the reason why the cert has to be deleted on the balancer deletion?
The entire workflow, if I'm not mistaken, is to first work with Barbican API in 
order to create the cert bundle. And technically it is not yet connected to 
anything else.
After that you create the balancer, specifying the link to where the cert 
bundle is.
From this perspective, why one should expect the cert bundle to be deleted?

For me personally it is the same as deletion of the image automatically once 
the instance got deleted :/

Sorry if I'm missing the context.

On Fri, Jan 27, 2017 at 2:19 AM, Adam Harwell 
> wrote:

Yeah, I believe it was because we intended to leave it up to the specific 
certificate manager to determine what needs to be done -- we are treating it as 
a delete, and if the cert manager wants to do a true delete, they can. I'll 
agree the verb is not perfectly clear, but the driver author should make sure 
the correct action is taken regardless of the function name.

It's possible we should just rename the function to something like 
"unget_cert", which sounds a bit nonsensical but is possibly still clearer. I 
remember at the time I wrote this being frustrated with trying to name the 
function and wanting to just move on. T_T

   --Adam (rm_work)

PS: Did we remove the local cert manager yet? Now I need to check... I hope so, 
because it's not actually usable, nor can it be without API modifications 
(which we discussed but never actually implemented or even fully agreed on).

On Wed, Jan 25, 2017, 17:50 Jiahao Liang (Frankie) 
> wrote:
Thanks rm_work.

I also notice something need to be handled properly.

For barbican, the delete_cert() only deregisters the cert without actually 
delete it. That's safe for us to call during 
delete_listener()/delete_loadbalancer().

But if the user uses other cert_manager by any chance, say the 
local_cert_manager, the same delete_cert() method will do a real delete of the 
cert.

Probably we need to implement register_consumer()/remove_consumer() method for 
cert_manager and call them in neutron_lbaas as well.


On Wed, Jan 25, 2017 at 10:48 Adam Harwell 
> wrote:

I've got this on my list of things to look at -- I don't know if it was you I 
was talking with on IRC the other day about this issue, but I'm definitely 
aware of it. As soon as we are past the Ocata feature freeze crunch, I'll take 
a closer look.

My gut says that we should be calling the delete (which is not a real delete) 
when the LB is deleted, and not doing so is a bug, but I'll need to double 
check the logic as it has been a while since I touched this.

--Adam (rm_work)

On Mon, Jan 23, 2017, 18:38 Jiahao Liang (Frankie) 
> wrote:
Hi community,

I created a loadbalancer with a listener with protocol as "TERMINATED_HTTPS" 
and specify --default-tls-container-ref with a ref of secret container from 
Barbican.
However, after I deleted the listener, the lbaas wasn't removed from barbican 
container consumer list.

$openstack secret container get 
http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
++-+
| Field  | Value
   |
++-+
| Container href | 
http://192.168.20.24:9311/v1/containers/453e8905-d42b-43bd-9947-50e3acf499f4
|
| Name   | tls_container2   
   |
| Created| 2017-01-19 12:44:07+00:00
   |
| Status | ACTIVE   
   

Re: [openstack-dev] [octavia] Nominating German Eichberger for Octavia core reviewer

[German Eichberger]

Glad to  be back!

Thanks for the trust,
German

From: Michael Johnson <johnso...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Monday, January 23, 2017 at 11:41 AM
To: "'OpenStack Development Mailing List (not for usage questions)'" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [octavia] Nominating German Eichberger for Octavia 
core reviewer

With that vote we have quorum.  Welcome back German!

Michael


From: Kosnik, Lubosz [mailto:lubosz.kos...@intel.com]
Sent: Sunday, January 22, 2017 12:24 PM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [octavia] Nominating German Eichberger for Octavia 
core reviewer

+1, welcome back.

Lubosz

On Jan 20, 2017, at 2:11 PM, Miguel Lavalle 
<mig...@mlavalle.com<mailto:mig...@mlavalle.com>> wrote:

Well, I don't vote here but it's nice to see German back in the community. 
Welcome!

On Fri, Jan 20, 2017 at 1:26 PM, Brandon Logan 
<brandon.lo...@rackspace.com<mailto:brandon.lo...@rackspace.com>> wrote:
+1, yes welcome back German.
On Fri, 2017-01-20 at 09:41 -0800, Michael Johnson wrote:
> Hello Octavia Cores,
>
> I would like to nominate German Eichberger (xgerman) for
> reinstatement as an
> Octavia core reviewer.
>
> German was previously a core reviewer for Octavia and neutron-lbaas
> as well
> as a former co-PTL for Octavia.  Work dynamics required him to step
> away
> from the project for a period of time, but now he has moved back into
> a
> position that allows him to contribute to Octavia.  His review
> numbers are
> back in line with other core reviewers [1] and I feel he would be a
> solid
> asset to the core reviewing team.
>
> Current Octavia cores, please respond with your +1 vote or an
> objections.
>
> Michael
>
> [1] http://stackalytics.com/report/contribution/octavia-group/90
>
>
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubs<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubs>
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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] Where will Neutron go in future?

[German Eichberger]

You are correct LBaaS development has moved to the Octavia team. However, 
Octavia will have a way for 3rd party load balancers to plug in instead of the 
Octavia load balancing solution. The Octavia team is currently deciding if it 
should continue to support the Haproxy namespace driver as part of Octavia. If 
you have questions, feel free to stop by the Octavia meeting [1] or send an 
e-mail tagged [Octavia].

German

[1] http://eavesdrop.openstack.org/#Octavia_Meeting

From: Nate Johnston 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Sunday, December 18, 2016 at 10:12 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: Re: [openstack-dev] [neutron] Where will Neutron go in future?

The neutron-fwaas team is an active and enthusiastic participant in the Neutron 
stadium, and is targeting FWaaS v2 to complete in the Ocala release. Once FWaaS 
v2 is complete, the neutron-fwaas team will start deprecating FWaaS v1 in the 
Pike cycle.

--N.

On Sun, Dec 18, 2016 at 9:56 PM zhi 
> wrote:
Deal all.

I have some questions about what will Neutron does in next releases.

As far as I know, LBaaSv2 will be deprecated in next 2 releases, maybe P 
release, we will not see LBaaSv2 anymore, isn't it? Instead of LBaaSv2( HAProxy 
driver based ), Octavia will be the only LBaaS solution, isn't it?

What's about namespace based L3 router? Do we have any ideas about NFV solution 
in L3 router just like Octavia?

Finally, where will Neutron *aaS go in future? Now, vpnaas was not part of 
neutron governance. What about fwaas? Do we deprecated it in next releases?

I wish someone could give some exact words about these. I will thanks a lot. :)


Thanks
Zhi Chang


__

OpenStack Development Mailing List (not for usage questions)

Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

Re: [openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

[German Eichberger]

+1

On 12/16/16, 12:35 PM, "Brandon Logan"  wrote:

+1!

On Fri, 2016-12-16 at 00:58 +0100, Armando M. wrote:
> Hi neutrinos,
> 
> I would like to propose Ryan and Nate as the go-to fellows for
> service-related patches.
> 
> Both are core in their repos of focus, namely neutron-dynamic-routing 
> and neutron-fwaas, and have a good understanding of the service
> framework, the agent framework and other bits and pieces. At this
> point, entrusting them with the responsibility is almost a formality.
> 
> Cheers,
> Armando
> 
> [1] https://review.openstack.org/#/c/411536/
> _
> _
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

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

[German Eichberger]

+1 (even if I can’t vote)

From: Edgar Magana 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Friday, December 16, 2016 at 12:46 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

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

Awesome! Well done Miguel!  +1

Edgar

From: "Armando M." 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Thursday, December 15, 2016 at 3:14 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