Re: [Openstack-operators] Rescheduling neutron dhcp agents?

Yeah, it's an odd one for sure, in my experience at least they do need to be manually re-scheduled. On Sun, 6 Aug 2017 at 11:27 Curtis wrote: > I'm in the process of testing out moving around some neutron services. > I'm starting with dhcp-agent. I've got neutron set to

Re: [Openstack-operators] Ubuntu package for Octavia

I highly recommend looking in to Giftwrap for that, until there's UCA packages. The thing missing from the packages that Giftwrap will produce is init scripts, config file examples, and the various user and directory setup stuff. That's easy enough to put into config management or a separate

Re: [Openstack-operators] [openstack-operators][ceph][nova] How do you handle Nova on Ceph?

On Mon, 2016-10-10 at 13:29 +, Adam Kijak wrote: > Hello, > > We use a Ceph cluster for Nova (Glance and Cinder as well) and over > time, > more and more data is stored there. We can't keep the cluster so big > because of  > Ceph's limitations. Sooner or later it needs to be closed for adding

Re: [Openstack-operators] Rados Gateway to Swift migration

gone now. > Thanks, > Kevin > ________ > From: Xav Paice [xavpa...@gmail.com] > Sent: Wednesday, October 05, 2016 12:12 PM > To: George Mihaiescu > Cc: OpenStack Operators > Subject: Re: [Openstack-operators] Rados Gateway to Swift migration >

Re: [Openstack-operators] Rados Gateway to Swift migration

far and that's one of the reasons for using Swift instead. There were limitations with permissions that we found very difficult to get around, without having a data collection user added to each and every project. > Thank you, > George > > > On Oct 5, 2016, at 1:57 AM, Xav

Re: [Openstack-operators] Rados Gateway to Swift migration

On Wed, 2016-10-05 at 15:42 +1100, Blair Bethwaite wrote: > Nice! But I'm curious, why the need to migrate? Hmm. I want to be diplomatic since both are great for their thing. For us, the main reason was simply that we wanted replication of the object storage between regions (we started the

Re: [Openstack-operators] Rados Gateway to Swift migration

On Tue, 2016-10-04 at 17:48 -0600, Curtis wrote: > Maybe you have someone on staff who loves writing lua (for haproxy)? :) > Well, maybe not that far, but yeah we're now thinking down that route. If we get there, I'll quickly write something up about it. Many thanks for the suggestion :)

Re: [Openstack-operators] Rados Gateway to Swift migration

_________ > From: Xav Paice [xavpa...@gmail.com] > Sent: Tuesday, October 04, 2016 2:45 PM > To: Curtis > Cc: OpenStack Operators > Subject: Re: [Openstack-operators] Rados Gateway to Swift migration > > On Tue, 2016-10-04 at 07:18 -0600, Curtis wrote: >

Re: [Openstack-operators] Rados Gateway to Swift migration

On Tue, 2016-10-04 at 07:18 -0600, Curtis wrote: > On Mon, Oct 3, 2016 at 3:31 PM, Xav Paice <xavpa...@gmail.com> wrote: > > Hi, > > > > We're in the process of migrating our object storage from Rados Gateway > > to Swift, and I was wondering if anyone has experi

Re: [Openstack-operators] Kilo ->-> Mitaka anyone have notes :)

FWIW, I did that with Cinder and it was great except for one DB change we had to make regarding the server name for volumes - http://dischord.org/2015/12/22/cinder-multi-backend-with-multiple-ceph-pools/ is a pretty good description of what I saw. I suspect that was just a poor configuration from

Re: [Openstack-operators] Packaging Virtualenvs

Can I suggest that using the tool https://github.com/openstack/giftwrap might make live a bunch easier? I went down a similar path with building Debs in a venv using dh_virtualenv, with some good success when I sorted the shebang. I later found that the debs produced by Giftwrap are not only very

Re: [Openstack-operators] VPNaaS and FWaaS

On 3 May 2016 at 05:03, Matt Jarvis wrote: > Thanks for the clarification Kyle. > > On 2 May 2016 at 14:33, Kyle Mestery wrote: > >> On Fri, Apr 29, 2016 at 8:01 AM, Matt Jarvis >> wrote: >> > I know there are

Re: [Openstack-operators] Cloud Upgrade Strategies

On 10 March 2016 at 19:26, Yuriy Brodskiy wrote: > building a new cloud is not practical for real production environments. > even if you can afford it, how do you migrate data? > > We have been doing upgrades for a while now, and came up with few basic > principles: > 1) you

Re: [Openstack-operators] Service Catalog TNG urls

On 7 December 2015 at 14:33, Clint Byrum wrote: > > Indeed, this is one paradigm where it actually creates a hardened core, > not a squisy one, so I think it's not a terrible idea. > > I tend to agree, just wish we were already there :) > > > What I mean is, you'd just have

Re: [Openstack-operators] [ceilometer][keystone][billing] RBAC restrictions of Ceilometer's Event API prevents billing of Openstack cloud

I don't fully understand the architecture of our rating project, but as I understand it we use a service with rights to read ceilometer info (in our case, pollsters and notifications) and then aggregate that into another database which we query to get the actual billing information. We bill

Re: [Openstack-operators] Service Catalog TNG urls

On 7 December 2015 at 05:38, Clint Byrum wrote: > Excerpts from Xav Paice's message of 2015-12-05 13:26:23 -0800: > > > > > I respect that this is what works for you and we shouldn't require you to > change your ways without good reason. However, I just want to point out > that

[Openstack-operators] Neutron getting stuck creating namespaces

Hi, Over the last few months we've had a few incidents where the process to create network namespaces (Neutron, OVS) on the network nodes gets 'stuck' and prevents not only the router it's trying to create from finishing, but all further namespace operations too. This has usually finished up

Re: [Openstack-operators] Running mixed stuff Juno & Kilo , Was: cinder-api with rbd driver ignores ceph.conf

We're running mixed Juno and Kilo, and upgrading one component at a time. Two issues with that so far: 1. The puppet modules don't play nice together (Juno/Kilo) - there was some serious re-factor done between those releases and they don't work at all together. I hacked the Juno modules to write

[Openstack-operators] Fwd: OPs Midcycle location discussion.

For us NZ (and maybe Aus) folk to attend, getting to Europe is (literally) twice the distance of US, but Asia is about the same (language aside).I find the Summit really valuable in that a large and diverse group get together and the discussion is live, and in the same time zone - I'd be sad

Re: [Openstack-operators] [puppet] Can we install OpenStack components using puppet but through source?

It's possible to do this if you build your own packages and name them the same as the distro packages - then make sure that you have all the deps etc as well. I'm making packages for Ubuntu by re-using some of the Ubuntu Cloud Archive, some of Debian, and some of my own packaging code, and

Re: [Openstack-operators] Kilo upgrade challenges

On Wed, Nov 11, 2015 at 4:43 PM, Leslie-Alexandre DENIS < > cont...@ladenis.fr> wrote: > >> Le 11/11/2015 05:46, Xav Paice a écrit : >> >> Hi, >> >> Late to the party, I'm only just doing the Kilo upgrade now (with a >> couple of projects going dir

[Openstack-operators] Kilo upgrade challenges

Hi, Late to the party, I'm only just doing the Kilo upgrade now (with a couple of projects going direct to Liberty). I seem to have hit a bit of a snag, and I've now spent a bit too long banging my head against this, was wondering if anyone else has advice/experiences to share. If it's a "you

Re: [Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?

On 06/08/15 07:56, Kyle Mestery wrote: Operators: We (myself, Paul and Doug) are looking to better understand who might be using Neutron's VPNaaS code. We're looking for what version you're using, how long you're using it, and if you plan to continue deploying it with future upgrades. Any

Re: [Openstack-operators] Dynamic Policy

On 06/08/15 04:01, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the

Re: [Openstack-operators] Problem with migration from Havana to IceHouse

On 21/01/15 23:43, Alvise Dorigo wrote: Hi, I've an Havana IaaS composed by: 1 controller node 1 network node 1 compute node and using Neutron as networking, and rabbitmq as AMQP. The network node runs the agents (dhcp, l3, openvswitch, metadata). The controller runs Keystone, glance,