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

[Nir Magnezi]

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  wrote:

> +1
> Definitely a good contributor for the octavia community.
>
> 发自我的 iPhone
>
> > 在 2018年8月31日，上午11:24，Michael Johnson  写道：
> >
> > 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

[Nir Magnezi]

+1. Well earned Jacky, Congratulations!

On Tue, Mar 27, 2018 at 8:31 AM, Adam Harwell  wrote:

> +1, definitely a good contributor! Thanks especially for your work on the
> dashboard!
>
> On Tue, Mar 27, 2018 at 2:09 PM German Eichberger <
> german.eichber...@rackspace.com> wrote:
>
>> +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 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] [Octavia] Community meeting regarding providers support

[Nir Magnezi]

Hello,

We are going to have an Octavia community meeting to discuss providers[1]
support in Queens, on Tuesday  12/19/2017 at 16:00 to 17:00 UTC time.
The meeting will take place in Bluejeans[2].

Hope to see you there.

[1] https://review.openstack.org/#/c/509957/
[2] https://bluejeans.com/9935153617

Regards,
Nir Magnezi
__
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 Nir Magnezi as Octavia core reviewer

[Nir Magnezi]

Thanks everyone for your votes :-)
I'm really happy to become a member of this great team!

Nir

On Tue, Oct 10, 2017 at 1:28 AM, Michael Johnson <johnso...@gmail.com>
wrote:

> Ok, that is quorum.
>
> Congratulations Nir!
>
> Michael
>
>
> On Mon, Oct 9, 2017 at 3:18 PM, Adam Harwell <flux.a...@gmail.com> wrote:
> > +1
> >
> >
> > On Thu, Oct 5, 2017, 05:48 Daniel Mellado <daniel.mellado...@ieee.org>
> > wrote:
> >>
> >> +1
> >>
> >> Go, Nir, Go!
> >>
> >> congrats!
> >>
> >> On 10/05/2017 03:51 AM, German Eichberger wrote:
> >> > +1
> >> >
> >> > Welcome Nir, well earned.
> >> >
> >> > German
> >> >
> >> > On 10/4/17, 4:28 PM, "Michael Johnson" <johnso...@gmail.com> 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
> >> >
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack 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] Nominating German Eichberger for Octavia core reviewer

[Nir Magnezi]

I don't get a vote here, but it is indeed nice to see German back in the
Octavia community.

Nir

On Fri, Jan 20, 2017 at 7:41 PM, 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: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] - LBaaS and IPv6

[Nir Magnezi]

Yes.

On Sun, Jan 8, 2017 at 2:07 PM, Alex Stafeyev  wrote:

> Hi,
> Does lbaas support LB in ipv6 network?
>
> tnx
>
> --
> Alexander Stafeyev
> QE Engineer, Neutron, Openstack
> Red Hat
>
>
>
__
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][octavia]

[Nir Magnezi]

I would like to emphasize the importance of this issue.

Currently, all te LBaaS/Octavia gates are up on running (touch wood).
Nevertheless, this bug will become more apparent (aka broken gates) in the
next release of tempest (if we don't merge this fix beforehand).

The reason is that the issue occurs when you use tempest master,
while our gates currently use tempest tag 13.0.0 (as expected).

Nir

On Tue, Jan 3, 2017 at 11:04 AM, Genadi Chereshnya 
wrote:

> When running neutron_lbaas scenarios tests with the latest tempest version
> we fail because of https://bugs.launchpad.net/octavia/+bug/1649083.
>
> I would like if anyone can go over the patch that fixes the problem and
> merge it, so our automation will succeed.
> The patch is https://review.openstack.org/#/c/411257/
>
> Thanks in advance,
> Genadi
>
> __
> 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] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Nir Magnezi]

Hi Greg,

Thanks for the replay, comments inline.

On Wed, Jun 29, 2016 at 9:59 PM, Gregory Haynes <g...@greghaynes.net> wrote:

> On Wed, Jun 29, 2016, at 10:26 AM, Nir Magnezi wrote:
>
> Hello,
>
> Lately, I've been working on a fix[1] for the amhpora-agent, which
> currently only support Debian based flavors such as Ubuntu.
>
> The main Issues here:
> 1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX
> files which are accepted in Linux flavors such a RHEL, CentOS and Fedora,
> read more in the fix commit msg.
> 2. The usage of Flavor specific features such as 'upstart'.
>
> I would like to have a discussion about the second bullet mentioned above.
> Due to the fact that in Octavia the loadbalancer runs inside of an
> instance (Amphora), There are few actions that need to take place in the
> Amphora instance boot process:
> a. namespace and NIC created.
> b. amphora agent starts
> c. haproxy (and possibly keepalived) start
>
> The Amphora-agent leverages[2] the capabilities of 'upstart' to make that
> happen, which is a bit problematic if we wish it to work on other flavors.
> The default cloud image for Amphora today is Ubuntu, yet there are few
> more options[3] such as CentOS and Fedora.
> Unlike the Ubuntu base image, which uses 'sysvinit', The latter two
> flavors use 'systemd'.
> This creates incompatibility with the jinja2[4][5] templates used by the
> agent.
>
> The way I see it there are two possible solutions for this:
> 1. Include a systemd equivalent in the fix[1] that will essentially
> duplicate the functionality mentioned above and work in the other flavors.
> 2. Have a the amphora agent be the only binary that needs to be configured
> to start upon boot, and that agent will take care of plugging namespaces
> and NICs and also spawning needs processes. This is how it is done in lbaas
> and l3 agents.
>
> While the latter solution looks like a more "clean" design, the trade-off
> here is a bigger change to the amphora agent.
>
> [1] https://review.openstack.org/#/c/331841/
> [2]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
> [3]
> https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
> [4]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
> [5]
> https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2
>
>
> Thanks,
> Nir
>
>
> I have an alternative suggestion - Maybe we shouldn't be templating out
> the init scripts? What we are effectively doing here is code-gen which
> leads to problems exactly like this, and fixing it with more code gen
> actually makes the problem more difficult.
>
>
The incompatibility to systemd is not due to usage of templates and code
generated files is a nice and useful tool to have.


> I see two fairly straightforward ways to not require this templating:
>
> 1) Use the agent to write out config for the init scripts in to
> /etc/defaults/amphora and have the init scripts consume that file (source
> variables in that file). The init script can then simply be a static file
> which we can even bake in to the image directly.
>

systemd does not use init script, which is why the current code is
incompatible to the distros i mentioned.

>
> 2) Move the code which requires the templating in to another executable
> which the init scripts call out to. e.g. create a amphora-net-init
> executable that runs the same code as in the pre-up section of the upstart
> script. Then there is no need for templating in the init scripts themselves
> (they will all simply call the same executable) and we can also do
> something like bake init scripts directly in to the image.
>

I'm not sure I follow you here. but anyhow we cannot just give up the
templates. how would you handle the parameters currently passed to those
templates? some if them you cannot know in advance and just hardcode.

>
>
> My thinking is that this is only going to get more complex - what are we
> going to do to support the new ubuntu LTS which is systemd based? Or if
> folk show up with other distros that match neither? Its a lot easier to
> decouple the init scripts, which are target specific, from configuration
> specific components and avoid this issues all together.
>

Well, there is a solution that I mentioned in my first mail. both neutron
LBaaS and L3 agents take care of everything needed as far as namespaces ,
nics and processes. that would leave you with a single binary to activate
upon boot.


>
> HTH,
> Greg
>
>
Nir

[openstack-dev] [lbaas][octavia] suggestion for today's meeting agenda: How to make the Amphora-agent support additional Linux flavors

[Nir Magnezi]

Hello,

Lately, I've been working on a fix[1] for the amhpora-agent, which
currently only support Debian based flavors such as Ubuntu.

The main Issues here:
1. NIC hot plugs: Ubuntu's ethX.cfg files looks different from ifcfg-ethX
files which are accepted in Linux flavors such a RHEL, CentOS and Fedora,
read more in the fix commit msg.
2. The usage of Flavor specific features such as 'upstart'.

I would like to have a discussion about the second bullet mentioned above.
Due to the fact that in Octavia the loadbalancer runs inside of an instance
(Amphora), There are few actions that need to take place in the Amphora
instance boot process:
a. namespace and NIC created.
b. amphora agent starts
c. haproxy (and possibly keepalived) start

The Amphora-agent leverages[2] the capabilities of 'upstart' to make that
happen, which is a bit problematic if we wish it to work on other flavors.
The default cloud image for Amphora today is Ubuntu, yet there are few more
options[3] such as CentOS and Fedora.
Unlike the Ubuntu base image, which uses 'sysvinit', The latter two flavors
use 'systemd'.
This creates incompatibility with the jinja2[4][5] templates used by the
agent.

The way I see it there are two possible solutions for this:
1. Include a systemd equivalent in the fix[1] that will essentially
duplicate the functionality mentioned above and work in the other flavors.
2. Have a the amphora agent be the only binary that needs to be configured
to start upon boot, and that agent will take care of plugging namespaces
and NICs and also spawning needs processes. This is how it is done in lbaas
and l3 agents.

While the latter solution looks like a more "clean" design, the trade-off
here is a bigger change to the amphora agent.

[1] https://review.openstack.org/#/c/331841/
[2]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/listener.py#L128
[3]
https://github.com/openstack/octavia/blob/master/diskimage-create/diskimage-create.sh#L27
[4]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/upstart.conf.j2
[5]
https://github.com/openstack/octavia/blob/master/octavia/amphorae/backends/agent/api_server/templates/sysvinit.conf.j2


Thanks,
Nir
__
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] [lbaas] Mid-Cycle proposed for the week of August 22nd

[Nir Magnezi]

Hi Michael,

Will there be an option to participate from remote?

Thanks,
Nir

On Fri, Jun 10, 2016 at 1:51 AM, Michael Johnson 
wrote:

> Just a reminder, we have a proposed mid-cycle meeting set for the week
> of August 22nd in San Antonio.
>
> If you would like to attend and have not yet signed up, please add
> your name to the list on our etherpad:
>
> https://etherpad.openstack.org/p/lbaas-octavia-newton-midcycle
>
> Thank you,
> 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] [tripleO][Neutron] neutron-lbaas agent service placement

[Nir Magnezi]

Hi Qasim,

Replied inline to your non-triple-o specific related questions.
Also regarding your following email, any specific reason you try to use
LBaaSv1?
I highly recommend that you go with LBaaSv2 (you may still choose haproxy
if you wish), since LBaaSv1 is deprecated[1] and will be removed[2]
sometime in the future.

[1] https://wiki.openstack.org/wiki/ReleaseNotes/Liberty --> Deprecated
Features
[2] https://review.openstack.org/#/c/286381

Nir

On Mon, Mar 14, 2016 at 5:18 PM, Qasim Sarfraz  wrote:

> Hi Triple-O folks,
>
> I was planning to enable neutron-lbaas-agent on a overcloud deployment but
> couldn't find any useful documentation. Can someone please point me to the
> required documentation? Is there a heat/puppet workflow available for this
> service?
>
> Also I had following questions regarding neutron-lbaas service placement:
>
>- I am not able to find a network node or neutron node role in tripleo
>templates [1] consequently the service will be placed on controllers.
>Correct?
>- Is it possible to run multiple instances of this service and use
>HAproxy to provide VIP to the services?
>
> Do you mean HAProxy in from of the LBaaS agent? could you elaborate?
I have not tested this myself, but I suspect you will run into some
difficulties. The VIP for your loadbalancer is actually a neutron port. a
port contains a hostname in its binding information.

>
>- Is it possible to run the service on the compute nodes? If yes is
>there a installation workflow for this.
>
> Neutron wise, it should work as long as you have L2 agent (which you
should since it's a compute node) on your server.


> Tagged Neutron, as someone from the Neutron or sub-projects teams might
> have already have answers for these.
>
> [1] - https://github.com/openstack/tripleo-heat-templates
>
> --
> Regards,
> Qasim Sarfraz
>
> __
> 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