Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

2018-08-17 Thread Flint WALRUS
ar/log inside the amphora. > > Michael > On Thu, Aug 16, 2018 at 1:43 PM Flint WALRUS > wrote: > > > > Hi Michael, > > > > Ok, it was indeed an issue with the create_certificate.sh script for > centos that indeed improperly created the client.pem certificate.

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

2018-08-16 Thread Flint WALRUS
to the gunicorn server using the lb-mgmt-net ip of the amphora. Is there any logs regarding the gunicorn server where I could check why does the amphora is not able to found the api endpoint? Le mar. 14 août 2018 à 19:53, Flint WALRUS a écrit : > I’ll try to check the certificate format and m

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

2018-08-14 Thread Flint WALRUS
I’ll try to check the certificate format and make the appropriate change 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! >

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

2018-08-14 Thread Flint WALRUS
our gate > tests to setup the TLS certificates: > > https://github.com/openstack/octavia/blob/master/devstack/plugin.sh#L295-L305 > > Michael > On Tue, Aug 14, 2018 at 4:54 AM Flint WALRUS > wrote: > > > > > > Hi guys, > > > > I continue to work on m

[Openstack-operators] [OCTAVIA][KOLLA] - Self signed CA/CERTS

2018-08-14 Thread Flint WALRUS
Hi guys, I continue to work on my Octavia integration using Kolla-Ansible and I'm facing a strange behavior. As for now I'm working on a POC using restricted HW and SW Capacities, I'm facing a strange issue when trying to launch a new load-balancer. When I create a new LB, would it be using CLI

Re: [Openstack-operators] Live-migration experiences?

2018-08-07 Thread Flint WALRUS
Hi clint, matt. To be noticed that post-copy and auto-convergence are mutually exclusive. The drawbacks that we experienced with here is that live-migration using either way post-copy or auto-convergence will likely fail for application not being able to handle throttling. Although, post-copy is

Re: [Openstack-operators] [nova] StarlingX diff analysis

2018-08-07 Thread Flint WALRUS
Hi matt, everyone, I just read your analysis and would like to thank you for such work. I really think there are numerous features included/used on this Nova rework that would be highly beneficial for Nova and users of it. I hope people will fairly appreciate you work. I didn’t had time to

Re: [openstack-dev] [Openstack-operators] [nova] StarlingX diff analysis

2018-08-07 Thread Flint WALRUS
Hi matt, everyone, I just read your analysis and would like to thank you for such work. I really think there are numerous features included/used on this Nova rework that would be highly beneficial for Nova and users of it. I hope people will fairly appreciate you work. I didn’t had time to

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-08-03 Thread Flint WALRUS
t > they are not configured for production use and are not always stable. > > If you are using RDO or RedHat OpenStack Platform (OSP) those projects > do provide production images. > > Michael > > On Thu, Aug 2, 2018 at 12:32 AM Flint WALRUS > wrote: > > > > Ok ok, I’ll

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-08-02 Thread Flint WALRUS
t; > However we can also help with that during the review process. > > Michael > > On Tue, Jul 31, 2018 at 11:03 PM Flint WALRUS > wrote: > > > > Ok sweet! Many thanks ! Awesome, I’ll be able to continue our deployment > with peace in mind. > > > > Reg

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-08-01 Thread Flint WALRUS
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. > > Michael > > > On Tue, Jul 31, 2018 at 9:49 PM Flint WALRUS > wrote: > > &g

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-07-31 Thread Flint WALRUS
ns with centos 7 amphora has been passing. It should be in the > same /etc/octavia/amphora-agent.conf location as the ubuntu based > amphora. > > Michael > > > > On Tue, Jul 31, 2018 at 10:05 AM Flint WALRUS > wrote: > > > > Hi Michael, thanks a lot for that e

Re: [Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-07-31 Thread Flint WALRUS
be routed (it does not require L2 connectivity). > > Michael > > On Tue, Jul 31, 2018 at 2:00 AM Flint WALRUS > wrote: > > > > Hi Folks, > > > > I'm currently deploying the Octavia component into our testing > environment which is based on KOLLA. > &

[Openstack-operators] [OCTAVIA][KOLLA] - Amphora to control plan communication question.

2018-07-31 Thread Flint WALRUS
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

Re: [Openstack-operators] [kolla-ansible][octavia-role]

2018-07-17 Thread Flint WALRUS
a écrit : > 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: > > > > > &g

[Openstack-operators] [kolla-ansible][octavia-role]

2018-07-17 Thread Flint WALRUS
Hi guys, I'm a trying to install Octavia as a new service on our cloud and facing few issues that I've been able to manage so far, until this nova-api keypair related issue. When creating a loadbalancer with the following command: openstack --os-cloud loadbalancer create --name lb1

Re: [openstack-dev] [neutron][api[[graphql] A starting point

2018-06-22 Thread Flint WALRUS
Oh! That’s its truly a sweet sweet attention, that will indeed really help us to focus on what we have to do without having to goes through an extensive email back and forth :-) Thanks a lot!! Le ven. 22 juin 2018 à 22:48, Ed Leafe a écrit : > On Jun 15, 2018, at 5:42 PM, Gilles Dubreuil

Re: [openstack-dev] [neutron][api[[graphql] A starting point

2018-06-22 Thread Flint WALRUS
08:42, Gilles Dubreuil a écrit : > > > On 22/06/18 15:57, Flint WALRUS wrote: > > Hi everyone, > > Thanks for the updates and support, that appreciated. > > @Gilles, did you already implemented all the service types? > > > We have query types for networks and s

Re: [openstack-dev] [neutron][api[[graphql] A starting point

2018-06-21 Thread Flint WALRUS
don’t want to mess up having pieces of code everywhere. Thanks! Le ven. 22 juin 2018 à 06:44, Gilles Dubreuil a écrit : > > On 22/06/18 09:21, Tristan Cacqueray wrote: > > Hi Flint, > > On June 21, 2018 5:32 pm, Flint WALRUS wrote: > > Hi everyone, sorry for the late answer b

Re: [openstack-dev] [neutron][api[[graphql] A starting point

2018-06-21 Thread Flint WALRUS
Hi everyone, sorry for the late answer but I’m currently trapped into a cluster issue with cinder-volume that doesn’t give me that much time. That being said, I’ll have some times to work on this feature during the summer (July/August) and so do some coding once I’ll have catched up with your

Re: [Openstack-operators] [openstack-client] - missing commands?

2018-06-14 Thread Flint WALRUS
PM, Flint WALRUS wrote: > > Hi guys, I use the «new» openstack-client command as much as possible > > since a couple of years now, but yet I had a hard time recently to find > > equivalent command of the following: > > > > nova force-delete > > & > > The c

[Openstack-operators] [openstack-client] - missing commands?

2018-06-13 Thread Flint WALRUS
Hi guys, I use the «new» openstack-client command as much as possible since a couple of years now, but yet I had a hard time recently to find equivalent command of the following: nova force-delete & The command on swift that permit to recursively upload the content of a directory and

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-31 Thread Flint WALRUS
t; > I've also been told that Zuul nees GraphQL. > > Well basically the question is who doesn't need it? > > Cheers, > Gilles > > > > On 31/05/18 03:34, Flint WALRUS wrote: > > Hi Gilles, I hope you enjoyed your Summit!? > > Did you had any interesting talk to rep

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-30 Thread Flint WALRUS
> PS: Flint, Thank you for offering to be the advocate for Berlin. That's > great! > > > On 06/05/18 02:23, Flint WALRUS wrote: > > Hi Akihiro, > > Thanks a lot for this insight on how neutron behave. > > We would love to get support and backing from the neut

Re: [Openstack-operators] [openstack-dev][publiccloud-wg][k8s][octavia] OpenStack Load Balancer APIs and K8s

2018-05-28 Thread Flint WALRUS
> implementation: > https://www.haproxy.com/blog/haproxy_ingress_controller_for_kubernetes/ > > Cheers, > > Saverio > > 2018-05-28 19:09 GMT+02:00 Flint WALRUS : > > Hi everyone, I’m currently deploying Octavia as our global LBaaS for a > lot > > of various workload such

Re: [Openstack-operators] [openstack-dev][publiccloud-wg][k8s][octavia] OpenStack Load Balancer APIs and K8s

2018-05-28 Thread Flint WALRUS
Hi everyone, I’m currently deploying Octavia as our global LBaaS for a lot of various workload such as Kubernetes ingress LB. We use Queens and plan to upgrade to rocky as soon as it reach the stable release and we use the native Octavia APIv2 (Not a neutron redirect etc). What do you need to

Re: [Openstack-operators] Need feedback for nova aborting cold migration function

2018-05-23 Thread Flint WALRUS
We are using multiple storage backend / topology on our side ranging from ScaleIO to CEPH passing by local compute host storage (were we need cold storage) and VNX, I have to said that CEPH is our best bet. Since we use it we clearly reduced our outages, allowed our user advanced features such as

Re: [Openstack-operators] [OpenStack-Operators][OpenStack] Regarding production grade OpenStack deployment

2018-05-18 Thread Flint WALRUS
Hi amit, I’m using kolla-ansible as a solution on our own infrastructure, however, be aware that because of the nature of Openstack you wont be able to achieve zero downtime if your hosted application do not take advantage of the distributed natre of ressources or if they’re not basically Cloud

Re: [openstack-dev] [neutron][api][grapql] Proof of Concept

2018-05-05 Thread Flint WALRUS
Hi Akihiro, Thanks a lot for this insight on how neutron behave. We would love to get support and backing from the neutron team in order to be able to get the best PoC possible. Someone suggested neutron as a good choice because of it simple database model. As GraphQL can manage your behavior

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-05 Thread Flint WALRUS
Yeah, when I said foundation I’m talking about the community. @Gilles, count me on if you need someone to work with. Le sam. 5 mai 2018 à 17:20, Jeremy Stanley <fu...@yuggoth.org> a écrit : > On 2018-05-04 23:42:59 + (+0000), Flint WALRUS wrote: > [...] > > what opera

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-04 Thread Flint WALRUS
is discussion on the coming project thread. > > Thank you everyone and see you there. > > Cheers, > Gilles > > On 04/05/18 23:16, Flint WALRUS wrote: > > As clarify by Gilles and Kevin we absolutely can get GraphQL with the > control plan API and the workers api. >

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-04 Thread Flint WALRUS
As clarify by Gilles and Kevin we absolutely can get GraphQL with the control plan API and the workers api. Ok, how do start to work on that? What’s the next step? Which server library do we want to use? I personally use graphene with python as it is the library listed by the official GraphQL

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-03 Thread Flint WALRUS
It seems to be a fair way to do it. I do second the Neutron API as a good candidate. I’ll be happy to give a hand. @jay I’ve already sum my points upper, but I could definitely have better exemples if needed. I’m operating and dealing with a large (really) Openstack platform and GraphQL would

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-03 Thread Flint WALRUS
Exactly ! Le jeu. 3 mai 2018 à 19:55, Flint WALRUS <gael.ther...@gmail.com> a écrit : > It seems to be a fair way to do it. I do second the Neutron API as a good > candidate. > > I’ll be happy to give a hand. > > @jay I’ve already sum my points upper, but I could definitel

Re: [Openstack-operators] Need feedback for nova aborting cold migration function

2018-05-02 Thread Flint WALRUS
As an operator dealing with platforms that do cold migration I would like to be able to abort and rollback the process. That would give us a better service quality and availability. We do have no choices but to use cold migration on some of our remote sites as they don’t get a unified storage

Re: [openstack-dev] [api] REST limitations and GraghQL inception?

2018-05-02 Thread Flint WALRUS
t to help with future ML > searches. > > Please see inline too. > > On 02/05/18 07:37, Flint WALRUS wrote: > > Ok, here are my two cents regarding GraphQL integration within Openstack > and some thoughts around this topic. > > 1°/- Openstack SDK should still e

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

2018-05-01 Thread Flint WALRUS
highly help Openstack on more than just interfacing topics. Le mar. 1 mai 2018 à 05:00, Gilles Dubreuil <gdubr...@redhat.com> a écrit : > > > On 01/05/18 11:31, Flint WALRUS wrote: > > Yes, that’s was indeed the sens of my point. > > > I was just enforcing it, no worr

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

2018-04-30 Thread Flint WALRUS
of ops to keep their day to day tools by just having to convert their existing collections of handful requests. Or alternatively to provide a tool with similar features at least. Le mar. 1 mai 2018 à 03:18, Gilles Dubreuil <gdubr...@redhat.com> a écrit : > > > On 30/04/18 20:16, Fli

Re: [openstack-dev] [api] REST limitations and GraghGL inception?

2018-04-30 Thread Flint WALRUS
I would very much second that question! Indeed it have been one of my own wondering since many times. Of course GraphQL is not intended to replace REST as is and have to live in parallel but it would likely and highly accelerate all requests within heavily loaded environments. So +1 for this

Re: [Openstack-operators] How are you handling billing/chargeback?

2018-03-12 Thread Flint WALRUS
Hi lars, personally using an internally crafted service. It’s one of my main regret with Openstack, lack of a decent billing system. Le lun. 12 mars 2018 à 20:22, Lars Kellogg-Stedman a écrit : > Hey folks, > > I'm curious what folks out there are using for chargeback/billing

Re: [openstack-dev] [kolla][vote] core nomination for caoyuan

2018-03-12 Thread Flint WALRUS
+1 Le lun. 12 mars 2018 à 10:09, Marcin Juszkiewicz < marcin.juszkiew...@linaro.org> a écrit : > W dniu 12.03.2018 o 03:06, Jeffrey Zhang pisze: > > It is my pleasure to nominate caoyuan for kolla core team. > > +1 > > __ >

Re: [openstack-dev] Pros and Cons of face-to-face meetings

2018-03-08 Thread Flint WALRUS
To simply answer the question: Yes I have experience about this specific matter of things as I’m now working with the exact setup for more than 5 years. I’m even exclusively working remotely with some studios of my employer. It’s not that expensive as long as you get correct rules, hardware and

Re: [openstack-dev] Pros and Cons of face-to-face meetings

2018-03-08 Thread Flint WALRUS
Pretty easy, put the PTG online with a livestream on YouTube/Hangout/whatever platform that will then be saved and could even be watched later on! It’s just a matter of some hardware and a decent internet bandwidth that’s already available to almost every places where a PTG took place. Problem

Re: [Openstack-operators] AggregateMultiTenancyIsolation with multiple (many) projects

2018-02-06 Thread Flint WALRUS
ur answer. > As far as I understand CellsV2 are present in Pike and later. I need to > implement such use case in an Ocata Openstack based cloud > > Thanks, Massimo > > 2018-02-06 10:26 GMT+01:00 Flint WALRUS <gael.ther...@gmail.com>: > >> Aren’t CellsV2 more adapted

Re: [Openstack-operators] Octavia LBaaS - networking requirements

2018-02-06 Thread Flint WALRUS
myself from the cliff :-) Le mar. 6 févr. 2018 à 10:53, Volodymyr Litovka <doka...@gmx.com> a écrit : > Hi Flint, > > I think, Octavia expects reachibility between components over management > network, regardless of network's technology. > > > On 2/6/18 11:41 AM, Flint WAL

[Openstack-operators] Octavia LBaaS - networking requirements

2018-02-06 Thread Flint WALRUS
Hi guys, I’m wondering if the Octavia lb-mgmt-net can be a L2 provider network instead of a neutron L3 vxlan ? Is Octavia specifically relying on L3 networking or can it operate without neutron L3 features ? I didn't find anything specifically related to the network requirements except for the

Re: [Openstack-operators] AggregateMultiTenancyIsolation with multiple (many) projects

2018-02-06 Thread Flint WALRUS
Aren’t CellsV2 more adapted to what you’re trying to do? Le mar. 6 févr. 2018 à 06:45, Massimo Sgaravatto < massimo.sgarava...@gmail.com> a écrit : > Hi > > I want to partition my OpenStack cloud so that: > > - Project p1, p2, .., pn can use only compute nodes C1, C2, ... Cx > - Projects pn+1..

Re: [Openstack-operators] Dedicated Network node ?

2018-02-01 Thread Flint WALRUS
Interesting, could you provide an example ? Le jeu. 1 févr. 2018 à 22:48, Christian Berendt < bere...@betacloud-solutions.de> a écrit : > > > > On 1. Feb 2018, at 21:42, Flint WALRUS <gael.ther...@gmail.com> wrote: > > > > Don’t get it, are you talking

Re: [Openstack-operators] Dedicated Network node ?

2018-02-01 Thread Flint WALRUS
oud-solutions.de> a écrit : > > > > On 1. Feb 2018, at 19:42, Flint WALRUS <gael.ther...@gmail.com> wrote: > > > > I think that indeed make sens as because now a day most the > installations tend to either be within a dockerized solution or a > relatively fair

Re: [Openstack-operators] Dedicated Network node ?

2018-02-01 Thread Flint WALRUS
I think that indeed make sens as because now a day most the installations tend to either be within a dockerized solution or a relatively fair amont (3/4) of large hw nodes. One situation that would require dedicated hw would be a very large installation requiring you to lower the network pression

Re: [Openstack-operators] Passing additional parameters to KVM for a single instance

2018-01-26 Thread Flint WALRUS
I would rather suggest you to deal with flavor/images metdata and host aggregate for such segregation of cpu capacity and versionning. If someone have another technics I’m pretty curious of it too. Le ven. 26 janv. 2018 à 17:00, Gary Molenkamp a écrit : > I'm trying to import a

Re: [Openstack-operators] [publiccloud-wg]Public Cloud Feature List Hackathon Day 2

2018-01-11 Thread Flint WALRUS
Hi folks, I’ve just added an entry with the google doc regarding GraphQL API as it strike me yesterday, if you need further information feel free to contact me. Le jeu. 11 janv. 2018 à 08:32, Zhipeng Huang a écrit : > Hi Folks, > > Today we are gonna continue to comb

Re: [Openstack-operators] neutron and dns_domain

2018-01-10 Thread Flint WALRUS
As you’re using a L2 network topology and until all of your project use a different network you can do: domain=domain1,10.10.10.0/24 domain=domain2,20.20.20.0/24 Within the dnsmasq-neutron.conf file. Of course, restart the neutron-server service once done. Le mer. 10 janv. 2018 à 22:40, Jonathan

Re: [Openstack-operators] [publiccloud-wg] Missing features work session

2018-01-05 Thread Flint WALRUS
I'm thrilled to see improvement within this field of concerns and the way Openstack mature by listening from users, would them be architects, operators, end-users etc. I'm glade to see such initiative and for sure will be there! See you on Wednesday! Le ven. 5 janv. 2018 à 15:02, Tobias Rydberg

Re: [Openstack-operators] Openstack operational configuration improvement.

2017-12-18 Thread Flint WALRUS
Thank you very much @Akihiro and @Jeremy these answers are really useful and constructives. Akihiro, regarding your two points yes, they for sure will be challenging and I really plan to work on this feature as a horizon plugin at the beginning as you mentioned it. Here what I'm thinking to do

Re: [Openstack-operators] Openstack operational configuration improvement.

2017-12-18 Thread Flint WALRUS
a shared way. A common geometry to how we think of the stack. > > -Matt > > On Mon, Dec 18, 2017 at 10:39 AM, Flint WALRUS <gael.ther...@gmail.com> > wrote: > >> Hi arkady, >> >> Ok understood your point. >> >> However, as an operator and adminis

Re: [Openstack-operators] Openstack operational configuration improvement.

2017-12-18 Thread Flint WALRUS
e upgrade. > > Thanks, > > Arkady > > > > *From:* Flint WALRUS [mailto:gael.ther...@gmail.com] > *Sent:* Monday, December 18, 2017 7:29 AM > *To:* openstack-operators@lists.openstack.org > *Subject:* [Openstack-operators] Openstack operational configuration > improvement.

[Openstack-operators] Openstack operational configuration improvement.

2017-12-18 Thread Flint WALRUS
Hi everyone, I don't really know if this list is the good one, but I'll have my bet on it :D Here I go. Since many times now, I'm managing Openstack platforms, and one things that always amazed me is its lack of comprehensive configuration management for services within Horizon. Indeed, you