Re: [Openstack] how to sync quota usage our of sync in Rocky release

Starting I think in Pike or Queens nova no longer caches quota usages and calculates it on the fly so there is now no need to the command as quotas can’t get out of sync anymore. Cheers, Sam > On 20 Nov 2018, at 4:49 pm, Manuel Sopena Ballesteros > wrote: > > Dear Openstack community, >

Re: [Openstack-operators] RabbitMQ and SSL

957> Sam > On 1 Nov 2018, at 11:04 am, Sam Morrison wrote: > > Hi all, > > We’ve been battling an issue after an upgrade to pike which essentially makes > using rabbit with ssl impossible > > https://bugs.launchpad.net/oslo.messaging/+bug/1800957 > <https

[Openstack-operators] RabbitMQ and SSL

Hi all, We’ve been battling an issue after an upgrade to pike which essentially makes using rabbit with ssl impossible https://bugs.launchpad.net/oslo.messaging/+bug/1800957 We use ubuntu cloud archives so it might no exactly be olso

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

> On 26 Oct 2018, at 1:42 am, Dan Smith wrote: > >> I guess our architecture is pretty unique in a way but I wonder if >> other people are also a little scared about the whole all DB servers >> need to up to serve API requests? > > When we started down this path, we acknowledged that this

Re: [openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

> On 24 Oct 2018, at 4:01 pm, melanie witt wrote: > > On Wed, 24 Oct 2018 10:54:31 +1100, Sam Morrison wrote: >> Hi nova devs, >> Have been having a good look into cellsv2 and how we migrate to them (we’re >> still on cellsv1 and about to upgrade to queens and sti

[openstack-dev] [nova] nova cellsv2 and DBs / down cells / quotas

Hi nova devs, Have been having a good look into cellsv2 and how we migrate to them (we’re still on cellsv1 and about to upgrade to queens and still run cells v1 for now). One of the problems I have is that now all our nova cell database servers need to respond to API requests. With cellsv1 our

Re: [Openstack-operators] [neutron][lbaas][neutron-lbaas][octavia] Update on the previously announced deprecation of neutron-lbaas and neutron-lbaas-dashboard

Hi Michael, Are all the backends that are supported by lbaas supported by octavia? I can’t see a page that lists the supported backends. Eg. We use lbaas with the midonet driver and I can’t tell if this will still work when switching over? Thanks, Sam > On 29 Sep 2018, at 8:07 am, Michael

Re: [Openstack-operators] Openstack Kilo - Danger: There was an error submitting the form. Please try again.

Hi Anwar, The log message you posted below is not an error (it is at level DEBUG and can be ignored). I would look in your horizon logs and also. The API logs of nova/neutron/glance/cinder to see what’s going on. Good luck! Sam > On 28 Aug 2018, at 9:22 pm, Anwar Durrani wrote: > > Hi

Re: [Openstack-operators] [nova][cinder][neutron] Cross-cell cold migration

I think in our case we’d only migrate between cells if we know the network and storage is accessible and would never do it if not. Thinking moving from old to new hardware at a cell level. If storage and network isn’t available ideally it would fail at the api request. There is also ceph

Re: [openstack-dev] [nova][cinder][neutron] Cross-cell cold migration

I think in our case we’d only migrate between cells if we know the network and storage is accessible and would never do it if not. Thinking moving from old to new hardware at a cell level. If storage and network isn’t available ideally it would fail at the api request. There is also ceph

Re: [Openstack-operators] neutron-server memcached connections

Great, yeah we have also seen these issues with nova-api with keystonemiddle in newton and ocata. Thanks for the heads up as I was going to start digging deeper. Cheers, Sam > On 31 Jul 2018, at 10:09 am, iain MacDonnell > wrote: > > > Following up on my own question, in case it's

Re: [Openstack-operators] Ubuntu Kernel with Meltdown mitigation SSL issues

to your specific setup. > > How is Keystone API endpoint TLS terminated in your setup? > > AFAIK in our OpenStack labs we haven't observed anything like this > although > > we terminate TLS on Nginx or HAProxy. > > > > > > On Thu, Jan 18, 2018 at 4:36 AM

[Openstack-operators] Ubuntu Kernel with Meltdown mitigation SSL issues

Hi All, We updated our control infrastructure to the latest Ubuntu Xenial Kernel (4.4.0-109) which includes the meltdown fixes. We have found this kernel to have issues with SSL connections with python and have since downgraded. We get errors like: SSLError: SSL exception connecting to

Re: [Openstack-operators] Mixed service version CI testing

We usually upgrade nova last so would be helpful. Nectar has been running a mix of versions for a couple of years now and we treat each project as it’s own thing and upgrade everything separately. You can see what versions we run currently at

[openstack-dev] [nova] Listing servers with filters and policy

Hi Nova devs, I’m after some feedback on how to give “non-admin” users the ability to list instances using “admin” filters. https://review.openstack.org/#/c/526558/ Basically just trying to be able to do some finer grained permission handling as

Re: [Openstack-operators] [nova] Cinder cross_az_attach=False changes/fixes

Hi Matt, Just looking into this, > On 1 Jun 2017, at 9:08 am, Matt Riedemann wrote: > > This is a request for any operators out there that configure nova to set: > > [cinder] > cross_az_attach=False > > To check out these two bug fixes: > > 1.

Re: [Openstack-operators] Successful nova-network to Neutron Migration

Awesome! Glad to hear it all went well. Cheers, Sam > On 21 May 2017, at 4:51 am, Joe Topjian wrote: > > Hi all, > > There probably aren't a lot of people in this situation nowadays, but for > those that are, I wanted to report a successful nova-network to Neutron >

Re: [Openstack-operators] [openstack-dev] [nova][glance] Who needs multiple api_servers?

> On 1 May 2017, at 4:24 pm, Sean McGinnis wrote: > > On Mon, May 01, 2017 at 10:17:43AM -0400, Matthew Treinish wrote: >>> >> >> I thought it was just nova too, but it turns out cinder has the same exact >> option as nova: (I hit this in my devstack patch trying to

Re: [openstack-dev] [Openstack-operators] [nova][glance] Who needs multiple api_servers?

> On 1 May 2017, at 4:24 pm, Sean McGinnis wrote: > > On Mon, May 01, 2017 at 10:17:43AM -0400, Matthew Treinish wrote: >>> >> >> I thought it was just nova too, but it turns out cinder has the same exact >> option as nova: (I hit this in my devstack patch trying to

Re: [Openstack-operators] Trove Shadow Tenant

Hi Sergio, I’m very interested in this feature too, it might be worth asking in the openstack-trove IRC channel or on the openstack-dev mailing list (adding a [trove] in the subject should get their attention) to get some answers to this question. Cheers, Sam > On 4 Feb 2017, at 1:34 am,

Re: [Openstack-operators] What would you like in Pike?

I would love it if all the projects policy.json was actually usable. Too many times the policy.json isn’t the only place where authN happens with lots of hard coded is_admin etc. Just the ability to to have a certain role to a certain thing would be amazing. It makes it really hard to have

Re: [openstack-dev] [nova] nova-api-metadata managing firewall

Thanks Jens, Is someone able to change the status of the bug from won’t-fix to confirmed so its visible. Cheers, Sam > On 10 Jan 2017, at 10:52 pm, Jens Rosenboom <j.rosenb...@x-ion.de> wrote: > > 2017-01-10 4:33 GMT+01:00 Sam Morrison <sorri...@gmail.com > <m

Re: [Openstack-operators] RabbitMQ 3.6.x experience?

sable, 3.6.5 hasn’t had any problems for us. Sam > -Original Message- > From: Mike Dorman [mailto:mdor...@godaddy.com] > Sent: Monday, January 09, 2017 6:00 PM > To: Ricardo Rocha; Sam Morrison > Cc: OpenStack Operators > Subject: Re: [Openstack-operators] RabbitMQ 3.6.

[openstack-dev] [nova] nova-api-metadata managing firewall

Hi nova-devs, I raised a bug about nova-api-metadata messing with iptables on a host https://bugs.launchpad.net/nova/+bug/1648643 It got closed as won’t fix but I think it could do with a little more discussion. Currently nova-api-metadata will

Re: [Openstack-operators] RabbitMQ 3.6.x experience?

We’ve been running 3.6.5 for sometime now and it’s working well. 3.6.1 - 3.6.3 are unusable, we had lots of issues with stats DB and other weirdness. Our setup is a 3 physical node cluster with around 9k connections, average around the 300 messages/sec delivery. We have the stats sample rate

[openstack-dev] [cinder] pending review

Hi Cinder devs, I’ve had a review [1] waiting for some eyes for over a month now. What’s the process here, usually I get a response to a review in other projects in a day or two. Is there someone I need to alert or add to the review specifically for cinder patches? Thanks, Sam [1]

Re: [openstack-dev] [gnocchi] influxdb driver gate error

a newer version of influxdb installed. Any idea how to do this? I see they push out a custom ceph repo to install a newer ceph so I guess we’d need to do something similar although influx don’t provide a repo, just a deb. Sam > On 30 Nov. 2016, at 7:35 pm, Sam Morrison <sorri...@gma

Re: [openstack-dev] [gnocchi] influxdb driver gate error

> On 30 Nov. 2016, at 6:23 pm, Mehdi Abaakouk <sil...@sileht.net> wrote: > > > > Le 2016-11-30 08:06, Sam Morrison a écrit : >> 2016-11-30 06:50:14.969302 | + pifpaf -e GNOCCHI_STORAGE run influxdb >> -- pifpaf -e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox

[openstack-dev] [gnocchi] influxdb driver gate error

Have been working on my influxdb driver [1] and have managed to figure out the gate to get it to install the deps ect. Now I just get this cryptic error 2016-11-30 06:50:14.969302 | + pifpaf -e GNOCCHI_STORAGE run influxdb -- pifpaf -e GNOCCHI_INDEXER run mysql -- ./tools/pretty_tox.sh

Re: [Openstack-operators] need feedback about Glance image 'visibility' migration in Ocata

can see the image, but then you're also now making it determine if the image can be shared or not. Cheers, Sam On Fri, Nov 18, 2016 at 12:27 AM, Brian Rosmaita < brian.rosma...@rackspace.com> wrote: > On 11/17/16, 1:39 AM, "Sam Morrison" <sorri...@gmail.com> wrote: >

Re: [Openstack-operators] need feedback about Glance image 'visibility' migration in Ocata

> On 17 Nov. 2016, at 3:49 pm, Brian Rosmaita > wrote: > > Ocata workflow: (1) create an image with default visibility, (2) change > its visibility to 'shared', (3) add image members Unsure why this can’t be done in 2 steps, when someone adds an image member to

Re: [Openstack-operators] Audit Logging - Interested? What's missing?

Anybody using http://docs.openstack.org/developer/keystonemiddleware/audit.html ?? > On 17 Nov. 2016, at 11:51 am, Kris G. Lindgren wrote: > > I need to do a deeper dive on audit logging. > >

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

> On 4 Nov. 2016, at 1:33 pm, Emilien Macchi <emil...@redhat.com> wrote: > > On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison <sorri...@gmail.com > <mailto:sorri...@gmail.com>> wrote: >> Wow I didn’t realise puppet3 was being deprecated, is anyone actually us

Re: [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

> On 4 Nov. 2016, at 1:33 pm, Emilien Macchi <emil...@redhat.com> wrote: > > On Thu, Nov 3, 2016 at 9:10 PM, Sam Morrison <sorri...@gmail.com > <mailto:sorri...@gmail.com>> wrote: >> Wow I didn’t realise puppet3 was being deprecated, is anyone actually us

Re: [openstack-dev] [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

Wow I didn’t realise puppet3 was being deprecated, is anyone actually using puppet4? I would hope that the openstack puppet modules would support puppet3 for a while still, at lest until the next ubuntu LTS is out else we would get to the stage where the openstack release supports Xenial but

Re: [Openstack-operators] [puppet][fuel][packstack][tripleo] puppet 3 end of life

Wow I didn’t realise puppet3 was being deprecated, is anyone actually using puppet4? I would hope that the openstack puppet modules would support puppet3 for a while still, at lest until the next ubuntu LTS is out else we would get to the stage where the openstack release supports Xenial but

Re: [Openstack-operators] Ceilometer/oslo.messaging connect to multiple RMQ endpoints

That was me! and yes you can do it when consuming notifications with ceilometer-agent-notification Eg in our ceilometer.conf we have [notification] workers=12 disable_non_metric_meters=true store_events = true batch_size = 50 batch_timeout = 5 messaging_urls =

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

Hi Julien, > On 16 Sep 2016, at 7:46 PM, Julien Danjou wrote: > >> I could push it up to gerrit but I think something will need to change >> for it to run the influxdb tests? > > You can use pifpaf like we do for the indexer, InfluxDB is supported. > That should make it

Re: [Openstack-operators] Murano in Production

We run completely separate clusters. I’m sure vhosts give you acceptable security but it means also sharing disk and ram which means if something went awry and generated lots of messages etc. it could take your whole rabbit cluster down. Sam > On 17 Sep 2016, at 3:34 PM, Joe Topjian

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

as there are a few ways it could be architected. Cheers, Sam [1] gnocchi.tests.test_rest.MetricTest.test_add_measures_back_window > On 6 Sep 2016, at 11:24 AM, Sam Morrison <sorri...@gmail.com> wrote: > > Hi Julien, > >> On 5 Sep 2016, at 5:36 PM, Julien Danjou &l

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

The index lives in gnocchi index much like the other drivers, all that is stored in influx db is the samples (time, metric_id, value) Sam > Max > From: Sam Morrison <sorri...@gmail.com> > Sent: September 5, 2016 9:24:21 PM > To: Julien Danjou > Cc: OpenStack Development Mail

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

Hi Julien, > On 5 Sep 2016, at 5:36 PM, Julien Danjou <jul...@danjou.info> wrote: > > On Mon, Sep 05 2016, Sam Morrison wrote: > > Hi Sam, > >> The issue I’m having are with the tests. Because the continuous queries are >> asynchronous and there is no c

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

failing everything is working quite well. I’m going to start some load testing soon to see what it’s like when pushing in a lot of metrics. Wondering if there would be time to talk about this in Barcelona. Cheers, Sam > On 4 Aug 2016, at 2:59 PM, Sam Morrison <sorri...@gmail.com> wrote

Re: [Openstack-operators] Designate service

Hi Alexandra, I don’t think that is supported in designate yet, I think there is/was a blueprint floating around somewhere for this but not sure if anyone has looked at implementing. If you wanted to code this up yourself you could also do this with a notification handler that looks for the

Re: [openstack-dev] [gnocchi] Support for other drivers - influxdb

gt; wrote: > > On Tue, Aug 02 2016, Sam Morrison wrote: > > Hi Sam! > >> We have been using gnocchi for a while now with the influxDB driver >> and are keen to get the influxdb driver back into upstream. >> >> However looking into the code and ho

Re: [Openstack-operators] Blazar? (Reservations and/or scheduled termination)

> On 4 Aug 2016, at 3:12 AM, Kris G. Lindgren wrote: > > We do something similar. We give everyone in the company an account on the > internal cloud. By default they have a user- project. We have a > Jenkins job that adds metadata to all vm’s that are in user-

[openstack-dev] [gnocchi] Support for other drivers - influxdb

Hi Gnocchi Devs, We have been using gnocchi for a while now with the influxDB driver and are keen to get the influxdb driver back into upstream. However looking into the code and how it’s arranged it looks like there are a lot of assumptions that the backend storage driver is carbonara based.

Re: [Openstack-operators] [gnocchi] monitoring storage use case inquiry

Hi Gordon, We are using the influxDB backend and we have our retention policies set to: Every minute for an hour Every 10 minutes for a day Every hour for a year Currently we hover around 8,000 instances. We understand the influxDB driver was taken out of gnocchi, bit annoyed as it wasn’t

Re: [Openstack-operators] [oslo] RabbitMQ queue TTL issues moving to Liberty

> On 28 Jul 2016, at 10:17 PM, Dmitry Mescheryakov <dmescherya...@mirantis.com> > wrote: > > > > 2016-07-27 2:20 GMT+03:00 Sam Morrison <sorri...@gmail.com > <mailto:sorri...@gmail.com>>: > >> On 27 Jul 2016, at 4:05 AM, Dmitry Mescheryakov &l

Re: [Openstack-operators] [oslo] RabbitMQ queue TTL issues moving to Liberty

> On 27 Jul 2016, at 4:05 AM, Dmitry Mescheryakov <dmescherya...@mirantis.com> > wrote: > > > > 2016-07-26 2:15 GMT+03:00 Sam Morrison <sorri...@gmail.com > <mailto:sorri...@gmail.com>>: > The queue TTL happens on reply queues and fanout queues. I

Re: [Openstack-operators] [oslo] RabbitMQ queue TTL issues moving to Liberty

> I don't think we can make case with sigkill any better. Other than that, the > issue could be investigated on Neutron side, maybe number of messages could > be reduced there. > > Thanks, > > Dmitry > > 2016-07-25 9:27 GMT+03:00 Sam Morrison <sorri...@gmail.com

[Openstack-operators] [oslo] RabbitMQ queue TTL issues moving to Liberty

We recently upgraded to Liberty and have come across some issues with queue build ups. This is due to changes in rabbit to set queue expiries as opposed to queue auto delete. See https://bugs.launchpad.net/oslo.messaging/+bug/1515278 for more information. The fix for this bug is in liberty

Re: [Openstack-operators] OpenStack mitaka using swift as backend for glance

Hi Michael, This would indicate that glance can’t find the swift endpoint in the keystone catalog. You can either add it to the catalog or specify the swift url in the config. Cheers, Sam > On 15 Jul 2016, at 9:07 PM, Michael Stang > wrote: > > Hi everyone,

Re: [openstack-dev] [puppet] [desginate] An update on the state of puppet-designate (and designate in RDO)

We (NeCTAR) use puppet-designate on Ubuntu 14.04 with Liberty. Cheers, Sam > On 6 Jul 2016, at 11:47 AM, David Moreau Simard wrote: > > Hi ! > > tl;dr > puppet-designate is going under some significant updates to bring it > up to par right now. > While I will try to ensure

Re: [openstack-dev] [nova] Rabbit-mq 3.4 crashing (anyone else seen this?)

We had some issues related to this too, we ended up changing our collect_statistics_interval to 30 seconds as opposed to the default which is 5 I think. We also upgraded to 3.6.2 and that version is very buggy and wouldn’t recommend anyone to use it. It has a memory leak and some other nasty

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

I’ve done kilo -> mitaka with Keystone and all worked fine. Nothing special I needed to do. If you’re wanting to do live upgrades with nova you can’t skip a version from my understanding. Sam > On 25 Jun 2016, at 4:16 AM, Jonathan Proulx wrote: > > Hi All, > > I about

Re: [Openstack-operators] Keystone's DB_SYNC from Kilo to Liberty

That usually means your DB is at version 86 (you can check the DB table to see, the table is called migration_version or something) BUT your keystone version is older and doesn’t know about version 86. Is it possible the keystone version your running is older and doesn’t know about version 86?

Re: [Openstack-operators] [Openstack-Operators] Keystone cache strategies

though the default cache time is 10 seconds for revocation lists. I might just set that to some large number to limit this traffic a bit. Sam > On Jun 21, 2016 5:55 PM, "Sam Morrison" <sorri...@gmail.com > <mailto:sorri...@gmail.com>> wrote: > >> O

Re: [Openstack-operators] [Openstack-Operators] Keystone cache strategies

> On 22 Jun 2016, at 9:42 AM, Matt Fischer <m...@mattfischer.com> wrote: > > On Tue, Jun 21, 2016 at 4:21 PM, Sam Morrison <sorri...@gmail.com > <mailto:sorri...@gmail.com>> wrote: >> >> On 22 Jun 2016, at 1:45 AM, Matt Fischer <m...@mattfischer

Re: [Openstack-operators] [Openstack-Operators] Keystone cache strategies

> > On 22 Jun 2016, at 1:45 AM, Matt Fischer wrote: > > I don't have a solution for you, but I will concur that adding revocations > kills performance especially as that tree grows. I'm curious what you guys > are doing revocations on, anything other than logging out of

[Openstack-operators] Duplicates and confusion in nova policy.json files

Now that policy files in nova Liberty apparently work I’m going through the stock example one and see that there are duplicate entries in the policy.json like compute:create:forced_host os_compute_api:servers:create:forced_host Which one do I use to change who can do forced_host? both or a

Re: [Openstack] [oslo] Issues with pbr when building custom packages

Jun 2016, at 4:25 AM, Jeremy Stanley <fu...@yuggoth.org> wrote: > > On 2016-06-09 08:16:11 +1000 (+1000), Sam Morrison wrote: > [...] >> I'm packaging nova, we have a bunch of custom commits and extra >> back ports in our version. Having the git hash in there is >> ext

Re: [Openstack] [oslo] Issues with pbr when building custom packages

> On 9 Jun 2016, at 8:16 AM, Sam Morrison <sorri...@gmail.com> wrote: > > > >> On 8 Jun 2016, at 10:51 PM, Doug Hellmann <d...@doughellmann.com> wrote: >> >> Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000: >>> We have

Re: [Openstack] [oslo] Issues with pbr when building custom packages

> On 8 Jun 2016, at 10:51 PM, Doug Hellmann wrote: > > Excerpts from Sam Morrison's message of 2016-06-08 16:59:37 +1000: >> We have been building our own packages for a few years now and I’ve just >> started to build packages for liberty. >> >> I got an error from pbr

[Openstack-operators] oslo_messaging, rabbit, ssl and mitaka and xenial

Hi all, We’ve been trying out some mitaka packages as well as some Xenial hosts and have been having some issues with rabbit and SSL. If using rabbitMQ 3.6.x on Trusty I can’t get a mitaka host (oslo_messaging 4.6.1, python-amqp 1.4.9) to connect to rabbit over SSL. If I use rabbitMQ 3.6.x

Re: [Openstack-operators] Ops Meetup event sizes

As an operator what should I prioritise now the main summit is changing, the thing formally known as the summit or the ops mid cycle? Will there be operator sessions at the summit still? Sorry if this has already been mentioned but still not 100% sure how operators fit into the new model.

Re: [Openstack-operators] [openstack-dev] [glance] Proposal for a mid-cycle virtual sync on operator issues

I’m hoping some people from the Large Deployment Team can come along. It’s not a good time for me in Australia but hoping someone else can join in. Sam > On 26 May 2016, at 2:16 AM, Nikhil Komawar wrote: > > Hello, > > > Firstly, I would like to thank Fei Long for

Re: [openstack-dev] [glance] Proposal for a mid-cycle virtual sync on operator issues

I’m hoping some people from the Large Deployment Team can come along. It’s not a good time for me in Australia but hoping someone else can join in. Sam > On 26 May 2016, at 2:16 AM, Nikhil Komawar wrote: > > Hello, > > > Firstly, I would like to thank Fei Long for

Re: [Openstack-operators] [craton] Versions of Python to support for Craton

I’m in favour of using 3.5. We are in the process of moving things to ubuntu xenial and 3.5 is native there. BTW when is Craton planning on getting into openstack gerrit etc? Sam > On 25 May 2016, at 6:20 AM, Jim Baker wrote: > > tl;dr - any reason why Craton should

Re: [Openstack-operators] Nova cells patches against Liberty

y uuid and I > think vm_state are set at that point. The name accessor method references > self.id, which (for some reason) is not lazy loadable. > > So I tried moving the _ensure_cells_system_metadata later in the save method, > after the object is loaded from the database (here:

Re: [Openstack-operators] [openstack-dev] [glance] glance-registry deprecation: Request for feedback

> On 14 May 2016, at 5:36 AM, Flavio Percoco <fla...@redhat.com> wrote: > >> On 5/12/16 9:20 PM, Sam Morrison wrote: >> >> We find glance registry quite useful. Have a central glance-registry api >> is useful when you have multiple datacenters all w

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

> On 14 May 2016, at 5:36 AM, Flavio Percoco <fla...@redhat.com> wrote: > >> On 5/12/16 9:20 PM, Sam Morrison wrote: >> >> We find glance registry quite useful. Have a central glance-registry api >> is useful when you have multiple datacenters all w

Re: [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

We find glance registry quite useful. Have a central glance-registry api is useful when you have multiple datacenters all with glance-apis and talking back to a central registry service. I guess they could all talk back to the central DB server but currently that would be over the public

Re: [openstack-dev] [Openstack-operators] [glance] glance-registry deprecation: Request for feedback

We find glance registry quite useful. Have a central glance-registry api is useful when you have multiple datacenters all with glance-apis and talking back to a central registry service. I guess they could all talk back to the central DB server but currently that would be over the public

Re: [Openstack-operators] Nova cells patches against Liberty

Hi Mike, I’ve also been working on these and have some updated patches at: https://github.com/NeCTAR-RC/nova/commits/stable/liberty-cellsv1 There are a couple of patches that you have in your tree that need updating for Liberty. Mainly around supporting the v2.1 API and more things moved to

Re: [Openstack-operators] Nova-network -> Neutron Migration

> On 9 Dec 2015, at 2:16 PM, Tom Fifield wrote: > > NeCTAR used this script (https://github.com/NeCTAR-RC/novanet2neutron ) with > success to do a live nova-net to neutron using Juno. That’s correct except we were on Kilo. I’m not sure I would try to do this on Icehouse

[Openstack-operators] [cinder] upgrade juno -> kilo (near live)

Hi All, We have got some patches that allows a near live upgrade of Cinder from Juno -> Kilo. It allows juno cinder-volumes to live with kilo API and schedulers. You basically need to ensure your juno hosts all have the patch Run the kilo DB migrations then upgrade api and scheduler to kilo.

Re: [Openstack-operators] How do I install specific versions of openstack/puppet-keystone

Can you get R10k to NOT install dependencies listed in metadata etc.? We use puppet-librarian and it can’t and so we have to change every puppet module eg. [1] as some of the dependencies break things for us. Sam [1]

Re: [Openstack-operators] Informal Ops Meetup?

I’ll be there, talked to Tom too and he said there may be a room we can use else there is plenty of space around the dev lounge to use. See you tomorrow. Sam > On 29 Oct 2015, at 6:02 PM, Xav Paice wrote: > > Suits me :) > > On 29 October 2015 at 16:39, Kris G. Lindgren

Re: [Openstack-operators] Neutron DHCP failover bug

> On 30 Sep 2015, at 3:48 pm, John Dewey wrote: > > Why not run neutron dhcp agents on both nodes? Yeah have tried this too. We don’t do this due to metadata, DHCP adds a static route to the metadata agent (which is the same as the network node running DHCP). If the network

[Openstack-operators] Neutron DHCP failover bug

Hi All, We are running Kilo and have come across this bug https://bugs.launchpad.net/neutron/+bug/1410067 Pretty easy to replicate, have 2 network nodes, shutdown 1 of them and DHCP etc. moves over to the new host fine. Except doing a

Re: [openstack-dev] [Openstack-operators] [cinder] [all] The future of Cinder API v1

Yeah we’re still using v1 as the clients that are packaged with most distros don’t support v2 easily. Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our “volume” endpoint to point to v2 (we have a volumev2 endpoint too) and the client breaks. $ cinder list ERROR: OpenStack

Re: [Openstack-operators] [openstack-dev] [cinder] [all] The future of Cinder API v1

Yeah we’re still using v1 as the clients that are packaged with most distros don’t support v2 easily. Eg. with Ubuntu Trusty they have version 1.1.1, I just updated our “volume” endpoint to point to v2 (we have a volumev2 endpoint too) and the client breaks. $ cinder list ERROR: OpenStack

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

> On 24 Sep 2015, at 6:19 pm, Sylvain Bauza wrote: > > Ahem, Nova AZs are not failure domains - I mean the current implementation, > in the sense of many people understand what is a failure domain, ie. a > physical unit of machines (a bay, a room, a floor, a datacenter). >

Re: [Openstack-operators] Potential deprecation of cinder.cross_az_attach option in nova

We very much rely on this and I see this is already merged! Great another patch I have to manage locally. I don’t understand what the confusion is. We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone. We don’t

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

Just got alerted to this on the operator list. We very much rely on this. We have multiple availability zones in nova and each zone has a corresponding cinder-volume service(s) in the same availability zone. We don’t want people attaching a volume from one zone to another as the network won’t

Re: [openstack-dev] [nova][cinder] how to handle AZ bug 1496235?

> On 24 Sep 2015, at 9:59 am, Andrew Laski wrote: > > I was perhaps hasty in approving that patch and didn't realize that Matt had > reached out for operator feedback at the same time that he proposed it. Since > this is being used in production I wouldn't want it to be

Re: [Openstack-operators] Adding v1 LIKE support to python-glanceclient releases 1.x.x

I’d just like things like image-list to work under the new client :-) https://bugs.launchpad.net/python-glanceclient/+bug/1492887 > On 10 Sep 2015, at 8:41 am, Nikhil Komawar wrote: > > Hi all, > > We recently release python-glanceclient 1.0.0 and it has the default >

Re: [Openstack-operators] kilo - neutron - ipset problems?

Hi Kris, We are moving to neutron in a month and are hitting this in our pre prod environment too. Sam > On 2 Sep 2015, at 6:32 am, Kris G. Lindgren wrote: > > Hello, > > We ran into this again today. > > I created bug:

Re: [Openstack-operators] Juno and Kilo Interoperability

Yeah we run a multitude of versions at the same time. We usually run N and N-1 in the same env but have also done N-2 (eg. Havana, Icehouse and Juno) Currently we are mainly Juno (keystone, heat, ceilometer, cinder) with a couple of icehouse things lying around. We are in the progress of

[Openstack-operators] [puppet] module dependencies and different openstack versions

We currently use our own custom puppet modules to deploy openstack, I have been looking into the official openstack modules and have a few barriers to switching. We are looking at doing this at a project at a time but the modules have a lot of dependencies. Eg. they all depend on the keystone

Re: [Openstack-operators] [keystone][all] Deprecating slash ('/') in project names

Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This

Re: [openstack-dev] [Openstack-operators] [keystone][all] Deprecating slash ('/') in project names

Do you mean project names or project IDs? Sam On 3 Jul 2015, at 12:12 am, Henrique Truta henriquecostatr...@gmail.com wrote: Hi everyone, In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], which allows cloud operators to organize projects in hierarchies. This

Re: [Openstack-operators] Help improve Neutron!

Hi Piet, Is this a UX focused interview? Sam On 23 Jun 2015, at 6:04 am, Kruithof, Piet pieter.c.kruithof...@hp.com wrote: Hi Folks, The OpenStack UX team is looking for six people that would be willing to participate in a one hour interview. We’re specifically looking for folks

Re: [Openstack-operators] Help improve Neutron!

On 6/22/15, 5:54 PM, Sam Morrison sorri...@gmail.com wrote: Hi Piet, Is this a UX focused interview? Sam On 23 Jun 2015, at 6:04 am, Kruithof, Piet pieter.c.kruithof...@hp.com wrote: Hi Folks, The OpenStack UX team is looking for six people that would be willing to participate

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 17 Jun 2015, at 8:35 pm, Neil Jerram neil.jer...@metaswitch.com wrote: Hi Sam, On 17/06/15 01:31, Sam Morrison wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public networks and 10 “service networks

Re: [Openstack-operators] [openstack-dev] [nova] [neutron] Re: How do your end users use networking?

On 17 Jun 2015, at 8:35 pm, Neil Jerram neil.jer...@metaswitch.com wrote: Hi Sam, On 17/06/15 01:31, Sam Morrison wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public networks and 10 “service networks

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 18 Jun 2015, at 2:59 am, Neil Jerram neil.jer...@metaswitch.com wrote: On 17/06/15 16:17, Kris G. Lindgren wrote: See inline. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 6/17/15, 5:12 AM, Neil Jerram

Re: [Openstack-operators] [openstack-dev] [nova] [neutron] Re: How do your end users use networking?

On 17 Jun 2015, at 10:56 am, Armando M. arma...@gmail.com wrote: On 16 June 2015 at 17:31, Sam Morrison sorri...@gmail.com mailto:sorri...@gmail.com wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public

Re: [openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

On 17 Jun 2015, at 10:56 am, Armando M. arma...@gmail.com wrote: On 16 June 2015 at 17:31, Sam Morrison sorri...@gmail.com mailto:sorri...@gmail.com wrote: We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want. We have 10 “public

  1   2   >