Ok perfect, I’ll have a look at the whole process and try to cleanup all my
note and make a clear documentation of them.
For the image I just choose to goes the CICD way with DIB and successfully
get a centos working image.
I’m now facing a SSL handshake issue, but I’ll try to fix it as I suspect
Hi there.
We track our bugs/RFE in storyboard, but patches go into the OpenStack gerrit.
There is a new contributor guide here if you have not contributed to
OpenStack before: https://docs.openstack.org/contributors/
As for images, no we don't as an OpenStack group. We have nightly
builds here: h
Ok ok, I’ll have a look at the guidelines and make some documentation patch
proposal once our POC will be working fine.
Do I have to propose these patch through storyboard or launchpad ?
Oh BTW, one last question, is there an official Octavia Amphora pre-build
iso?
Thanks for the link.
Le mer. 1
Hi Flint,
Yes, our documentation follows the OpenStack documentation rules. It
is in RestructuredText format.
The documentation team has some guides here:
https://docs.openstack.org/doc-contrib-guide/rst-conv.html
However we can also help with that during the review process.
Michael
On Tue, Ju
Ok sweet! Many thanks ! Awesome, I’ll be able to continue our deployment
with peace in mind.
Regarding the documentation patch, does it need to get a specific format or
following some guidelines? I’ll compulse all my annotations and push a
patch for those points that would need clarification and a
No worries, happy to share. Answers below.
Michael
On Tue, Jul 31, 2018 at 9:49 PM Flint WALRUS wrote:
>
> Hi Michael,
>
> Oh ok! That config-drive trick was the missing part! Thanks a lot! Is there a
> release target for the API vs config-drive thing? I’ll have a look at an
> instance as soo
Hi Michael,
Oh ok! That config-drive trick was the missing part! Thanks a lot! Is there
a release target for the API vs config-drive thing? I’ll have a look at an
instance as soon as I’ll be able to log into one of my amphora.
By the way, three sub-questions remains:
1°/ - What is the best place
Hi Flint,
Happy to help.
Right now the list of controller endpoints is pushed at boot time and
loaded into the amphora via config drive/nova.
In the future we plan to be able to update this list via the amphora
API, but it has not been developed yet.
I am pretty sure centos is getting the config
Hi Michael, thanks a lot for that explanation, it’s actually how I
envisioned the flow.
I’ll have to produce a diagram for my peers understanding, I maybe can
share it with you.
There is still one point that seems to be a little bit odd to me.
How the amphora agent know where to find out the hea
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 amphora
Hi Folks,
I'm currently deploying the Octavia component into our testing environment
which is based on KOLLA.
So far I'm quite enjoying it as it is pretty much straight forward (Except
for some documentation pitfalls), but I'm now facing a weird and hard to
debug situation.
I actually have a har
11 matches
Mail list logo