you for your support and patience during this transition,
Michael Johnson
Octavia PTL
[1]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html
[3] https
No issue with using an L2 network for the lb-mgmt-net.
It only requires the following:
Controllers can reach amphora-agent IPs on the TCP bind_port (default 9443)
Amphora-agents can reach the controllers in the
controller_ip_port_list via UDP (default )
This can be via an L2 lb-mgmt-net
notations and push a patch
> for those points that would need clarification and a little bit of formatting
> (layout issue).
>
> Thanks for this awesome support Michael!
> Le mer. 1 août 2018 à 07:57, Michael Johnson a écrit :
>>
>> No worries, happy to share. Answers below
y understand the
> underlying mechanisms before we goes live with the solution.
>
> G.
>
> Le mer. 1 août 2018 à 02:36, Michael Johnson a écrit :
>>
>> Hi Flint,
>>
>> Happy to help.
>>
>> Right now the list of controller endpoints is pushed at boot time a
Hi Flint,
We don't have a logical network diagram at this time (it's still on
the to-do list), but I can talk you through it.
The Octavia worker, health manager, and housekeeping need to be able
to reach the amphora (service VM at this point) over the lb-mgmt-net
on TCP 9443. It knows the
anks for your help!
> Le mar. 31 juil. 2018 à 18:15, Michael Johnson a écrit :
>>
>> Hi Flint,
>>
>> We don't have a logical network diagram at this time (it's still on
>> the to-do list), but I can talk you through it.
>>
>> The Octavia worker, health m
; Thanks for the link.
> Le mer. 1 août 2018 à 17:57, Michael Johnson a écrit :
>>
>> Hi Flint,
>>
>> Yes, our documentation follows the OpenStack documentation rules. It
>> is in RestructuredText format.
>>
>> The documentation team has some gu
Hi there Flint.
Octavia fully supports using self-signed certificates and we use those
in our gate tests.
We do not allow non-TLS authenticated connections in the code, even
for lab setups.
This is a configuration issue or certificate file format issue. When
the controller is attempting to
hange if
>> required or let you know if I’ve got something specific regarding that topic.
>>
>> Kind regards,
>> G.
>> Le mar. 14 août 2018 à 19:52, Flint WALRUS a écrit :
>>>
>>> Hi Michael, thanks a lot for your quick response once again!
>>&
Right. I am not familiar with the kolla role either, but you are
correct. The keypair created in nova needs to be "owned" by the
octavia service account.
Michael
On Tue, Jul 17, 2018 at 9:07 AM iain MacDonnell
wrote:
>
>
>
> On 07/17/2018 08:13 AM, Flint WALRUS wrote:
> > Hi guys, I'm a trying
Hi there.
I'm not sure what is happening there and I don't use kolla, so I need
to ask a few more questions.
Is that network ID being used for the VIP or the lb-mgmt-net?
Any chance you can provide a debug log paste from the API process for
this request?
Basically it is saying that network ID
Are the controller and the amphora using the same version of Octavia?
We had a python3 issue where we had to change the HMAC digest used. If
you controller is running an older version of Octavia than your
amphora images, it may not have the compatibility code to support the
new format. The
, ruled out signing_digest, so I'm
> >>> back to something related
> >>> to the certificates or the communication between the endpoints, or what
> >>> actually responds inside the amphora (gunicorn IIUC?). Based on the
> >>> "verify" fu
I am still catching up on e-mail from the weekend.
There are a lot of different options for how to implement the
lb-mgmt-network for the controller<->amphora communication. I can't
talk to what options Kolla provides, but I can talk to how Octavia
works.
One thing to note on the lb-mgmt-net
er mailing list: openstack-dev
[at] lists [dot] openstack [dot] org. Please prefix the subject with
'[openstack-dev][Octavia]'
Thank you for your support and patience during this transition,
Michael Johnson
Octavia PTL
[1] http://lists.openstack.org/pipermail/openstack-dev/2018-January/126836.html
mplemented/policy-in-code.html
Michael
On Fri, Sep 14, 2018 at 8:46 AM Lance Bragstad wrote:
>
>
>
> On Thu, Sep 13, 2018 at 5:46 PM Michael Johnson wrote:
>>
>> In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
>> which maps to t
In Octavia I selected[0] "os_load-balancer_api:loadbalancer:post"
which maps to the "os--api::" format.
I selected it as it uses the service-type[1], references the API
resource, and then the method. So it maps well to the API reference[2]
for the service.
[0]
17 matches
Mail list logo
