[openstack-dev] [Neutron][stable] How to backport database schema fixes

Hi, all It seems that currently it's hard to backport any database schema fix to Neutron [1] which uses alembic to manage db schema version. Nova has the same issue before and a workaround is to put some placeholder files before each release. So first do we allow db schema fixes to be backport to

Re: [openstack-dev] [Nova][libvirt]when deleting instance which is in migrating state, instance files can be stay in destination node forever

could we use Taskflow https://wiki.openstack.org/wiki/TaskFlow to manage task state and resource for this kind of tasks in Nova? Cinder has been an pilot to use Taskflow for volume backup tasks. anyone interested in this suggestion or has done some research to improve the live migration workflow?

[openstack-dev] [nova] where to expose network quota

Hi all, Now Neutron has its own quota management API for network related items(floating ips, security groups .etc) which are also manged by Nova. when using nova with neutron as network service, the network related quota items are stored in two different databases and managed by different APIs.

[openstack-dev] [Keystone] python-keystoneclient v3 functionality

Hi all, I am sorry if this has been discussed before, the question is will we support keystone v3 operation in python-keystoneclient? I know most of the v3 functionality have been implemented in python-openstackclient, but from the python-openstackclient wiki says, it's primarily a wrapper of

Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality

that is the correct direction. [1] https://review.openstack.org/#/c/81749/ https://review.openstack.org/#/c/81767/ 2014-04-01 12:08 GMT+08:00 Jamie Lennox jamielen...@redhat.com: On Tue, 2014-04-01 at 11:53 +0800, Yaguang Tang wrote: Hi all, I am sorry if this has been discussed

Re: [openstack-dev] [Keystone] python-keystoneclient v3 functionality

functionality On 04/01/2014 07:36 AM, Yaguang Tang wrote: Thanks Jamie, then the following question is do we intend to move other services client library V3 identity support to python-openstackclient? AFAIK it's poorly supported for Nova Cinder Neutron client library, and I am working

[openstack-dev] [Neutron] Release Notes for Icehouse

Hi all, I think it's important for our developers to publish an official Release Note as other core openstack projects does at the end of Icehouse development cycle, it contains the new features added and upgrade issue to be noticed by the users. any one like to be volunteer to help accomplish

Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!

How can I enable or trigger Mine Sweeper for VMware related patches? I have update a patch about VMware driver today https://review.openstack.org/#/c/51793/ . but haven't seen any posting results . 2013/10/18 Sean Dague s...@dague.net On 10/17/2013 02:29 PM, Dan Smith wrote: This system is

Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps

after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console , I have filed a bug to track this

Re: [openstack-dev] [Neutron]Tempest testing error

Hi Trinath, I think you missed some configuration in tempest.conf for your testing, the exception is duo to no public_network_id defined. an example of tempest.conf for upsteam gate tests is here for your reference

Re: [openstack-dev] [Horizon] Project list with turned-on policy in Keystone

I think this is an common requirement for users who want to keystone v3. I filed a blueprint for it https://blueprints.launchpad.net/horizon/+spec/domain-based-rbac. 2014-04-24 23:30 GMT+08:00 Roman Bodnarchuk roman.bodnarc...@indigitus.ch: Hello, As far as I can tell, Horizon uses

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

Frittoli, I think for other services we could achieve that by modifying the policy.json( add domain admin role and control what the cloud admin can do ) so that domain admin user is able to manage resources belong to users and projects in that domain. 2014-05-09 15:24 GMT+08:00 Frittoli,

Re: [openstack-dev] Hierarchical administrative boundary [keystone]

used to scope IAM resources and not very useful for end services. I think what we are lacking is unique role (role name) per service, having unique role names for each service (IAM, Nova, Swift ….) will resolve the problem mentioned below by Yaguang Tang. Please let me know why services

Re: [openstack-dev] [Horizon] Project list with turned-on policy in Keystone

this mean that there is no real support for non-default domains in Horizon? Thanks, Roman On 5/5/2014 2:30 PM, Yaguang Tang wrote: I think this is an common requirement for users who want to keystone v3. I filed a blueprint for it https://blueprints.launchpad.net/horizon/+spec/domain-based-rbac

Re: [openstack-dev] common codes

we put openstack common code in oslo , and sync to other projects to keep the common code in each project is aways up to date, when oslo is mature enough, then we will publish oslo as a openstack common library. the common code in each project just need to change from from nova.openstack.common

[openstack-dev] [nova] review request

Hi all, I'd appreciate if any of the nova-core reviewers could take a look at https://review.openstack.org/#/c/39226/, as this add keypair notification events. which is more like a small feature than a bug, I am callling review just in case after feature freeze it can't be accepted. -- Tang

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

tboot installer for years. > You are think in a way of developers, but the fact is that Fuel are widely used by various enterprises in the world wide, there are many security policies for enterprise to have no internet connection. > Thanks, > Igor > > > On Thu, Sep

Re: [openstack-dev] [Fuel] Remove MOS DEB repo from master node

t connectivity, it is about aligning >> things. >> >> > You are correct in that this thread is not explicitly about internet > connectivity, but they are related. Any changes to remove a local > repository and only provide an internet based solution makes internet > connectivity so

Re: [openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

gt; > On Thu, Jun 29, 2017 at 8:56 PM, gordon chung <g...@live.ca> wrote: > >> >> >> On 29/06/17 07:24 AM, Yaguang Tang wrote: >> > sinks: >> > - name: event_sink >> > transformers: >> > triggers: >> >

[openstack-dev] [ceilometer][panko] Ocata ceilometer event storage configuration

Hi all, I am using Ocata Ceilometer Gnocchi with Panko, Panko is configured to use MySQL as backend to store events, I configured Ceilometer event_pipeline.yaml as follow: sinks: - name: event_sink transformers: triggers: publishers: - direct:// -

Re: [openstack-dev] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

> UnicodeDecodeError: 'ascii' codec can't decode byte 0xde in position 4: > ordinal not in range(128) > 2017-08-05 18:14:19.100 1329257 ERROR cotyledon._utils > > > > On Sat, Aug 5, 2017 at 7:16 PM, Yaguang Tang <heut2...@gmail.com> wrote: > >> Hi gnocchi devs, &

[openstack-dev] [gnocchi][ceilometer] gnocchi-metricd error using redis as coordination

Hi gnocchi devs, I have an issue when using gnocchi 4.0, the storage backend is ceph, and tooz coordination is redis. currently gnocchi api in apache wsgi mode, only one controller node running gnocchi-metricd & gnocchi-statsd daemon. the error log of gnocchi-metricd is as follow. 2017-08-05

[openstack-dev] [gnocchi] Redis for storage backend

Hi all, I see the latest Gnocchi support using Redis as a storage backend, I am testing performance of Redis and Ceph, it seems using Redis as storage backend we can achieve more realtime metric data, gnocchi status shows there is always few metric to process. Is Redis a recommend storage

Re: [openstack-dev] [Openstack-operators] PCI pass through settings on a flavor without aliases on the API nodes

Hi Van, You can try to create a pci-passthrough port with PCI info, then create vm using that port without any alias. On Wed, Oct 18, 2017 at 11:27 PM, Eric Fried wrote: > Robert- > > No. > > Some day, once generic device management is baked, there will be.

Re: [openstack-dev] [gnocchi] Redis for storage backend

7 AM, Julien Danjou wrote: > > On Fri, Oct 13 2017, Yaguang Tang wrote: > > > >> I see the latest Gnocchi support using Redis as a storage backend, I am > >> testing performance of Redis and Ceph, it seems using Redis as storage > >> backend we can achieve more

Re: [openstack-dev] [gnocchi] Redis for storage backend

Hi Gordon， Thanks for your test results， we investigate more on our env, finally it turns out that our ceph cluster isn't work as expected. which made gnocchi performance decrease a lot. On Thu, Oct 19, 2017 at 1:09 AM, gordon chung <g...@live.ca> wrote: > > > On 2017-10-18 12

Re: [openstack-dev] [keystone][all] v2.0 API removal

Keystone is one project that all other OpenStack projects use, so personally I think the change to remove the API which are widely used should be discussed at TC meeting . As far as I know ,not all OpenStack projects support the keystone v3 domain (domain, project,user) as well as keystone, you

[openstack-dev] Fwd: [Openstack-operators][tc] [keystone][all] v2.0 API removal

Should this kind of change be discussed and have an agreement of the TC and User committee? -- Forwarded message -- From: Lance Bragstad Date: Fri, Oct 20, 2017 at 12:08 AM Subject: [Openstack-operators] [keystone][all] v2.0 API removal To: "OpenStack

Re: [openstack-dev] [keystone][all][tc] v2.0 API removal

effort to maintain it. On Fri, Oct 20, 2017 at 8:46 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2017-10-20 10:52:36 +0800 (+0800), Yaguang Tang wrote: > > Keystone is one project that all other OpenStack projects use, so > > personally I think the change to remove the