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 woul

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-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 backed

[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 oppo

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 get glance >> deployed

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 wrote: > > 2017-01-10 4:33 GMT+01:00 Sam Morrison <mailto:sorri...@gmail.com>>: >> Hi nova-devs, >

[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

[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] https://re

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

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 wrote: > >

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

> On 30 Nov. 2016, at 6:23 pm, Mehdi Abaakouk 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.sh >> 2016-11-3

[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 2016-11-

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

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

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 t

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 possible to run the uni

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 wrote: > > Hi Julien, > >> On 5 Sep 2016, at 5:36 PM, Julien Danjou wrote: >> >> On

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

x much like the other drivers, all that is stored in influx db is the samples (time, metric_id, value) Sam > Max > From: Sam Morrison > Sent: September 5, 2016 9:24:21 PM > To: Julien Danjou > Cc: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [ope

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

Hi Julien, > On 5 Sep 2016, at 5:36 PM, Julien Danjou 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 current way in influxdb

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 wrote: > > OK than

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

e, 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 how it’s arranged it looks like >>

[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-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 it is well tested a

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 bu

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 bringing up a few operator

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

> On 14 May 2016, at 5:36 AM, Flavio Percoco 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 with glance-apis and >>

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 Interne

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 Block

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). > All the AZs in Nova

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 removed without at > l

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] [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 > wrote: > > Hi everyone, > > In Kilo, keystone introduced the concept of Hierarchical Multitenancy[1], > which allows cloud operators to organize projects in hierarchies. This > concept is evolving

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 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" wrote: >>

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 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" network

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. wrote: > > > > On 16 June 2015 at 17:31, Sam Morrison <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

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

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 and depending on which compute node you land on you get attached to one of them. In neutron speak we have multiple shared externally rou

[openstack-dev] [nova] Tempest failure help

Hi nova devs, I have a patch https://review.openstack.org/#/c/181776/ where I have a failing tempest job which I can’t figure out. Can anyone help me? Cheers, Sam __ OpenStack D

Re: [openstack-dev] [nova] readout from Philly Operators Meetup

> On 11 Mar 2015, at 11:59 pm, Sean Dague wrote: > > Nova Rolling Upgrades > - > > Most people really like the concept, couldn't find anyone that had > used it yet because Neutron doesn't support it, so they had to big > bang upgrades anyway. I couldn’t make it to the ops s

Re: [openstack-dev] Taking a break..

Thanks for all the help Chris and all the best. Now on the lookout for another cells core I can harass and pass obscure bugs too. It was always reassuring knowing you’d probably already come across the issue and could point me to a review or git branch with a fix. Cheers, Sam > On 23 Oct 2014

Re: [openstack-dev] [Nova] Cells conversation starter

> On 23 Oct 2014, at 5:55 am, Andrew Laski wrote: > >> While I agree that N is a bit interesting, I have seen N=3 in production >> >> [central API]-->[state/region1]-->[state/region DC1] >>\->[state/region DC2] >> -->[state/region2 DC] >>

Re: [openstack-dev] [Openstack] [nova] Havana -> Icehouse upgrades with cells

On 25 Apr 2014, at 12:30 am, Chris Behrens wrote: >>> So, does your nova-conductor not have object version 1.13? As I was trying >>> to get at in a previous reply, I think the only way this can possibly work >>> is that you have Icehouse nova-conductor running in ALL cells. >> >> OK so in my

Re: [openstack-dev] [Openstack] [nova] Havana -> Icehouse upgrades with cells

Hey Chris, On 24 Apr 2014, at 4:28 pm, Chris Behrens wrote: > On Apr 23, 2014, at 6:36 PM, Sam Morrison wrote: > >> Yeah I’m not sure what’s going on, I removed my hacks and tried it using the >> conductor rpcapi service and got what I think is a recursive call in

Re: [openstack-dev] [Openstack] [nova] Havana -> Icehouse upgrades with cells

branch or else cells is doing something different when it comes to objects. I don’t think it is a cells issue though as debugging it, it seems like it just can’t back port a 1.13 object to 1.9. Cheers, Sam On 23 Apr 2014, at 1:01 am, Chris Behrens wrote: > > On Apr 19, 2014, at 11:08 P

[openstack-dev] Glance Icehouse RC bugs

Hi, We’ve found a couple of bugs in glance RC. They both have simple fixes that fix some major features, I’m wondering if some glance experts can cast their eye on them and if they qualify for icehouse. glance registry v2 doesn't work (This has got some attention already, thanks) https://bugs.l

Re: [openstack-dev] [Nova][Cells] compute api and objects

OK thanks for the info, I’ll have a look into these and add some bugs/patches. Cheers, Sam On 11 Dec 2013, at 10:21 am, Chris Behrens wrote: > On Dec 9, 2013, at 2:58 PM, Sam Morrison wrote: > >> Hi, >> >> I’m trying to fix up some cells issues related to objects

[openstack-dev] [Nova][Cells] compute api and objects

Hi, I’m trying to fix up some cells issues related to objects. Do all compute api methods take objects now? cells is still sending DB objects for most methods (except start and stop) and I know there are more than that. Eg. I know lock/unlock, shelve/unshelve take objects, I assume there are ot

Re: [openstack-dev] How to choose proper availablity-zone in Havana version with the same usage realized by JsonFilter in Folsom version?

On 7 Nov 2013, at 5:10 pm, hzguanqi...@corp.netease.com wrote: > Hi guys, > > In Folsom version, availability-zone info is stored in compute_nodes db > table, and so can be parsed by JsonFilter. > I can use JsonFilter to choose which(or except which) availability-zones to > build my instance.

Re: [openstack-dev] Shall backward compatibility env. vars be removed from python-clients?

I think you need to do option 2 and print deprecation warnings, then the question becomes for how long. I think there is a policy for this and that it is deprecate in N remove in N+1 Clients are a bit different so maybe keep it for ~6 months? Sam On 8 Nov 2013, at 10:49 am, Leandro Costantino

[openstack-dev] [Nova] upgrade_levels and cells

Hey, I’ve been playing with Grizzly -> Havana upgrade paths with cells. Having Havana at the api cell with Grizzly compute cells won’t work (don’t think it’s supposed too?) Having Grizzly at api level with Havana compute cell almost works, it seems the only major issue is the block_device_mappi

Re: [openstack-dev] [Swift] container forwarding/cluster federation blueprint

Hi, I'd be interested in the differences this has to using swift global clusters? Cheers, Sam On 12/10/2013, at 3:49 AM, "Coles, Alistair" wrote: > We’ve just committed a first set of patches to gerrit that address this > blueprint: > > https://blueprints.launchpad.net/swift/+spec/cluster

Re: [openstack-dev] [Ceilometer] Ceilometer and nova compute cells

On 31/07/2013, at 6:45 PM, Julien Danjou wrote: > On Wed, Jul 31 2013, Sam Morrison wrote: > > Hi Sam, > >> Does everything that gets stored in the datastore go through the >> ceilometer.collector.metering queue? > > If you only use the RPC publisher (which is

[openstack-dev] [Ceilometer] Ceilometer and nova compute cells

Hi, There is a blueprint [1] that I'd like to get involved with. I know quite a bit about cells but not much about ceilometer. I'm trying to figure out all the message flows to see where the best place would be to intercept the message and forward it up to a higher level rabbit server. Essenti

Re: [openstack-dev] Cells design issue

I like the idea of JSON config for this too, but then again config groups maybe be better as it keeps all configuration together and in the same format. Operators would prefer that I'd say. Sam On 15/06/2013, at 6:06 AM, Chris Behrens wrote: > Are the group names programmatically computed/ac