[openstack-dev] [horizon][release][infra] New xstatic package release proposal

TL;DR: "Releasing xstatic packages" https://review.openstack.org/#/c/253296/ xstatic is an existing standard for packaging up static resources for web development (HTML, Javascript and CSS) as Python modules. Horizon makes use of two dozen xstatic packages. We need a

[openstack-dev] [Congress] Python 3 ready

Congress can finally pass python34 gating. Here¹s the last patch needed to make it happen. https://review.openstack.org/#/c/253298/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [neutron] [networking-sfc] Temporary instructions

Here it is (I posted this in today's IRC meeting too). https://wiki.openstack.org/wiki/Neutron/ServiceInsertionAndChaining Thanks, Cathy From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com] Sent: Thursday, December 03, 2015 10:34 AM To: openstack-dev@lists.openstack.org Subject:

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi Ifat, > > > Let me see if I got this right: are you suggesting that we create > > > on-the-fly alarm definitions with no alarm_actions, for every > > > deduced > > alarm that we want to raise? And this will spare us the extra alarm > > evaluation in AODH? > > > > Yes. But, please note that

Re: [openstack-dev] [openstack-ansible] Install Openstack-Ansible

Hi Major, Thanks for the steps. To add a new container, we have followed the steps as mentioned in the extra_container.yml.example. Please find the sample designate.yml file attached and created as per the steps. To add the new roles in openstack-ansible repository, shall I create the

Re: [openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys wrote: > Hi all, > > Trying to prepare moving our repos to the OpenStack infrastructure, I > got reminded just how many repos we have in our GitHub organization > [1] - and how many of those seem to be deprecated or tangential. >

Re: [openstack-dev] [nova] Testing concerns around boot from UEFI spec

On Thu, Dec 03, 2015 at 07:42:43PM -0600, Matt Riedemann wrote: > I already mentioned this to sdague before the nova meeting today (these are > the things I think about while driving in the middle of nowhere), but option > #3 won't work because boot from UEFI requires libvirt>=1.9.0, which we

Re: [openstack-dev] [Murano] How to debug a failed deployment?

Vahid, The only reason HOT deployment could last forever is that Heat stack never enters Ready of Failed state. Please check what is the Heat stack status. I guess it is not Murano issue (except for the fact that we don't provide timeout for HOT deployment :) ) Sincerely yours, Stan Lagun

[OpenStack-Infra] New JJB release needed

If you run "tox -e jjb" locally in project-config, it will fail since it uses the latest JJB release which does not support the new template-name option. Could somebody do a new release, please? Thanks, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi SUSE LINUX

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

On Thu, Dec 3, 2015 at 7:25 PM, Thierry Carrez wrote: > Sandro Mathys wrote: >> On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto >> wrote: >>> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto >>> wrote: hi,

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

> shouldn't we switch tests to work with python2.7 instead of python2.6? Currently we run tests using both py26 and py27, see the * gate-fuel-web-python27 (openstack infra) * verify-fuel-web-py27 (fuel infra) So the question is should we drop py26 jobs? I think yes, we should.. but once CentOS

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

Hi, On Thu, Dec 3, 2015 at 11:49 AM, Igor Kalnitsky wrote: > > shouldn't we switch tests to work with python2.7 instead of python2.6? > > Currently we run tests using both py26 and py27, see the > > * gate-fuel-web-python27 (openstack infra) > * verify-fuel-web-py27

[Openstack-operators] Downgrade in Trove

Hello all, we from Trove, want to remove the downgrade fuctionality from our SQL Schema. This was a TC approved spec for all projects across OpenStack[1] and we need to follow this process as well. We would like to know if are there anyone using this functionality and that removing it would be a

Re: [openstack-dev] [Heat] get_reality implementation: default values, specified in config files

On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky wrote: > > Hello! > > During get_reality implementation next problem raised: if I don't specify > optional not update allowed property (like availabiliy_zone in > OS::Cinder::Volume), default value will be set for this

Re: [openstack-dev] [horizon] Proposal to add Richard Jones to horizon-core

+1 for both On Thu, Dec 3, 2015 at 2:57 AM, David Lyle wrote: > Let's try that again. > > I propose adding Richard Jones[1] to horizon-core. > > Over the last several cycles Richard has consistently been providing > great reviews, actively participating in the Horizon

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

On 3 December 2015 at 11:14, Li, Xiaoyan wrote: > Just to clear the data operations cinder needs to touch plaintext data are: > 1) Create volume from glance image > 2) Create glance image from volume > 3) Retype encrypted volumes. That is to change a volume from

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

Chunked Encoding is a bad idea with mod_wsgi in general. While enabling it like that is fine, you are not guaranteed to get 100% consistent results simply because the wsgi spec did not/does not support it. Not all versions of mod_wsgi can enable it. So, in short, officially keystone does not

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

Just want to make a couple of things clear: 1. Openstack-Infra is dropping py26 jobs support, as Andreas said, so once https://review.openstack.org/#/c/252448/ is merged all openstack projects (including Fuel, of course) won’t have py26 gates. 2. We still run py26 tests on Fuel-CI side and

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

Hi everybody, please, note that we faced next issue [0] during 7.0-MU1 testing and one of the possible solutions was to upgrade rabbitmq to 3.5.5. This issue is also present in 8.0 and affects at least one SWARM destructive test. [0] https://bugs.launchpad.net/fuel/+bug/1513511 On Thu, Dec 3,

[openstack-dev] [horizon] [QA] Improving Horizon Integration Tests

Hello, folks! As you probably already know, integration tests were recently made voting again in Horizon. Next logical step in ensuring Horizon/OpenStack stability is increasing their coverage. I've reworked initial GoogleDoc version of tests breakdown (wasn't very popular due to the restricted

[openstack-dev] [Fuel] CentOS7: merge freeze announcement

Hi All, 1. According to CentOS7 Merging plan [1] we assessed list of FF exceptions and decided to integrate remaining commits into CentOS7 merge plan. So if your patch was listed in FF exceptions list please contact Dmitry Teselkin to add it in our merge plan. 2. We are freezing all git

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

> possible to have a working py26 CI for the duration > of Centos 7 migration (or keep it even after that) I'd prefer to drop py26 as well as py27 from Fuel CI. We have openstack gating, that should be more than enough. :) Fuel CI should be kept for running Fuel UI tests. On Thu, Dec 3, 2015 at

[openstack-dev] [Manila] Tempest scenario tests vs. gate condition

Hi, We're working towards getting the devstack/CI parts ready to test the forthcoming ceph native driver, and have a question: will a driver be accepted into the tree if it has CI for running the api/ tempest tests, but not the scenario/ tempest tests? The context is that because the scenario

[openstack-dev] [Heat] get_reality implementation: default values, specified in config files

Hello! During get_reality implementation next problem raised: if I don't specify optional not update allowed property (like availabiliy_zone in OS::Cinder::Volume), default value will be set for this property in entity. This default value defined in configuration of entity's project (i.e. if I

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

On 12/02/2015 04:11 PM, Matt Riedemann wrote: > > > On 12/2/2015 2:33 PM, Jeremy Stanley wrote: >> [Apologies for the delayed reply, after more than a week without >> Internet access it's taking me more than a week to catch up with >> everything on the mailing lists.] >> >> On 2015-11-20

Re: [openstack-dev] [Murano] How to debug a failed deployment?

Hi Vahid, Could you provide your logs anyway? Please publish them to http://paste.openstack.org/ for example 2015-12-02 23:08 GMT+02:00 Vahid S Hashemian : > Hello, > > I am trying to deploy a hello world HOT package in murano but the > deployment runs forever and

Re: [openstack-dev] [heat][infra] heat-templates dsvm gate

From: Pavlo Shchelokovskyy [mailto:pshchelokovs...@mirantis.com] Sent: Thursday, December 03, 2015 1:20 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [heat][infra] heat-templates dsvm gate Hi all, I would like to discuss how to fix and improve

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi Ifat, > > One approach we can take, is that you configure aodh to pass each row > > event (e.g. each VM downed) wrapped in alarm notification to vitrage, > > then do some operation (e.g. deducing, aggregating) and store > > resource- level alarm without any alarm_actions, so that users can

Re: [openstack-dev] [Neutron] Evolving the stadium concept

Armando M. wrote: > On 2 December 2015 at 01:16, Thierry Carrez > wrote: >> Armando M. wrote: >> >> One solution is, like you mentioned, to make some (or all) of them >> >> full-fledged project teams. Be aware that this means the

[openstack-dev] [Fuel] Dropping python2.6 compatibility

Hi, During Fuel master migration to CentOS7 there was found a problem that tests get failed [0] for python2.6 As far as I can see it's a common practise to drop python2.6 compatibility [1], shouldn't we switch tests to work with python2.7 instead of python2.6? It looks like fuelclient will be

Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

>From paste logs.. 2015-11-13 18:07:00.926 INFO neutron.manager [-] Loading Plugin: *networking_sfc.services.sfc.plugin.SFCPlugin* 2015-11-13 18:07:00.974 INFO n*etworking_sfc.services.sfc.driver_manager* [-] Configured portchain driver names: ['dummy'] 2015-11-13 18:07:00.975 ERROR

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

Thank you, Ben. I agree with you, and just to clear the cinder operations which needs to decrypt volumes in following. On Dec 3, 2015 05:01, Ben Swartzlander wrote: > On 11/30/2015 09:04 AM, Coffman, Joel M. wrote: >> >> >> On 11/25/15, 11:33 AM, "Ben Swartzlander" >

Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick

From: Coffman, Joel M. [mailto:joel.coff...@jhuapl.edu] Sent: Thursday, December 3, 2015 2:07 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [cinder][nova]Move encryptors to os-brick From: "duncan.tho...@gmail.com"

[openstack-dev] [neutron][ceilometer]Meter for security group

Hi everyone: I want to meter security group. And I want to get those metric for ceilometer. 1. totle packets for vm/container through security group. 2. drop packets for vm/container through security group. And I want get the from iptables. Could somebody give me some comments.

Re: [openstack-dev] [Neutron] Bug deputy process

Hi Armando, On 12/02/2015 07:49 PM, Armando M. wrote: Hi neutrinos, It's been a couple of months that the Bug deputy process has been in place [1,2]. Since the beginning of Mitaka we have collected the following statistics (for neutron and neutronclient): Total bug reports: 373 * Fix

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

Roman, Thank you. This is great research. Could we have a conversation to discuss this? I'm especially interested in idempotency problems of the fuel-library modules and the common way to provide serialised data to the deployment. -- Best regards, Oleg Gelbukh Mirantis Inc On Tue, Dec 1, 2015

Re: [openstack-dev] [magnum] Using docker container to run COE daemons

On 11/28/2015 01:01 AM, Egor Guz wrote: Have you tested slave/agent inside container? I was under impression that it doesn’t work until somebody from Kolla team pointed me to the https://hub.docker.com/u/mesoscloud/. Also I belive you can try your approach without any changes at existing

Re: [openstack-dev] [magnum] Mesos Conductor

Hi Jay, Sorry I just saw your mail. I have pushed the patches for json-file support for client[1] and backend[2]. If the team accepts the support the json file support for container-create, I can link the client patch to your blueprint and you can add patches for other features you mentioned, if

Re: [openstack-dev] [midonet] What repos to migrate to OpenStack infrastructure

hi, On Wed, Dec 2, 2015 at 4:05 PM, Sandro Mathys wrote: > Hi all, > > Trying to prepare moving our repos to the OpenStack infrastructure, I > got reminded just how many repos we have in our GitHub organization > [1] - and how many of those seem to be deprecated or

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

On 2015-12-03 11:21, Evgeniy L wrote: Hi, During Fuel master migration to CentOS7 there was found a problem that tests get failed [0] for python2.6 As far as I can see it's a common practise to drop python2.6 compatibility [1], shouldn't we switch tests to work with python2.7 instead of

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto wrote: > On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto > wrote: >> hi, >> >> we are going to migrate networking-midonet meeting from slack to irc. >> the plan is to have it 7:00 UTC on every

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote: > Another question is our need to get alarms from other sources, like > Nagios, zabbix, ganglia, etc. We thought that Vitrage would query these > Alarms from each source directly, and then create alarms in AODH in the > same way as our deduced

Re: [openstack-dev] [Murano] How to debug a failed deployment?

Hi! Murano agent doesn't involved in the deployment of hot packages, that's why this setting doesn't help. Please attach agent logs and heat logs also (check if heat stack is created or not). Regards, Kate. Regards, Kate. On Thu, Dec 3, 2015 at 11:44 AM, Dmytro Dovbii

Re: [openstack-dev] [neutron][midonet] networking-midonet weekly irc meeting

Sandro Mathys wrote: > On Thu, Dec 3, 2015 at 1:07 PM, Takashi Yamamoto > wrote: >> On Mon, Nov 30, 2015 at 12:52 PM, Takashi Yamamoto >> wrote: >>> hi, >>> >>> we are going to migrate networking-midonet meeting from slack to irc. >>> the plan is to

Re: [openstack-dev] [nova] jsonschema for scheduler hints

2015-12-02 23:12 GMT+08:00 Sylvain Bauza : > > > Le 02/12/2015 15:23, Sean Dague a écrit : > >> We have previously agreed that scheduler hints in Nova are an open ended >> thing. It's expected for sites to have additional scheduler filters >> which expose new hints. The way we

Re: [openstack-dev] [ironic] specs process for ironic-inspector

FYI: the process is in effect now. Please submit specs to https://github.com/openstack/ironic-inspector-specs/ Approved specs will appear on http://specs.openstack.org/openstack/ironic-inspector-specs/ On 11/19/2015 02:19 PM, Dmitry Tantsur wrote: Hi folks! I've been dodging subj for some

Re: [openstack-dev] [Openstack-operators] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

On 12/03/2015 07:51 AM, Morgan Fainberg wrote: Chunked Encoding is a bad idea with mod_wsgi in general. While enabling it like that is fine, you are not guaranteed to get 100% consistent results simply because the wsgi spec did not/does not support it. Not all versions of mod_wsgi can enable

[Openstack-operators] Service Catalog TNG urls

For folks that don't know, we've got an effort under way to look at some of what's happened with the service catalog, how it's organically grown, and do some pruning and tuning to make sure it's going to support what we want to do with OpenStack for the next 5 years (wiki page to dive deeper here

Re: [openstack-dev] [kolla] Using existing ceph pools

This is a planned feature from the beginning, but not implemented. I have done this locally, but I have not submitted a patchset. You can expect this available and working by mitaka-2. On Dec 1, 2015 6:08 AM, "OpenStack Mailing List Archive" wrote: > Link:

[openstack-dev] Documentation containing external resource links & privacy breaches

Hi, On many occasion, I've seen our docs containing external links, with images containing src=foo.com/bar. In Debian, I am packaging these documentation, and lintian (the packaging linter for Debian) yells that there are privacy breaches. Below is an example with oslo.context. But that's only a

Re: [openstack-dev] [Fuel] Configuration management for Fuel 7.0

Folks, little bit more research done in regards #2 usability. I've selected 13 real-world tasks from customer (i.e. update flag X in nova.conf): - 6/13 require fuel-library patching (or is #2 unusable) - 3/13 are OK and can be done with #2 - 4/13 can be done with some limitations. If needed

Re: [Openstack] Database schema

Hi Dionisis, Reading your question I've remembered a python script that generates OpenStack ER diagrams and I've found it again: https://coderwall.com/p/pngadg/er-diagram-for-openstack-database It's really nice and simple, but it needed an update:

[openstack-dev] [Nova] How to check changes waiting for review

Hi, I wonder how you follow changes waiting for review. openstack-docs offers a Documentation Program Dashboard for this purpose . Inspired by that dashboard I prepared a link for Nova as well: http://goo.gl/Msq4Lb As I am quite new with the open source world, just to get used to

Re: [openstack-dev] [horizon]

Please take a look at https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload On Thu, Dec 3, 2015 at 5:21 PM Kyrylo Galanov wrote: > Hello, > > When a file is uploaded to Glance, Swift through Horizon it is stored > locally in a temporary

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On Thu, Dec 03, 2015 at 08:11:41AM -0500, Dan Prince wrote: > On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote: > > So, chatting with Giulio today about https://bugs.launchpad.net/heat/ > > +bug/1521944 > > has be thinking about $subject. > > > > The root case of that issue is essentially a

Re: [openstack-dev] [cloudkitty] Remove inactive contributors from cloudkitty-core

Hi, We didn't get your opinion Guillaume, are you approving it? Cheers - Forwarded message from Stéphane Albert - Date: Tue, 24 Nov 2015 11:51:42 +0100 From: Stéphane Albert To: openstack-dev@lists.openstack.org Subject:

[openstack-dev] [horizon]

Hello, When a file is uploaded to Glance, Swift through Horizon it is stored locally in a temporary directory in Horizon server. This is inefficient approach especially for big files. I would suggest to implement 'proxy' upload to Glance, Swift using chunk buffer instead of storing a file

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote: > One of Vitrage's goals is to gather information from different layers - > Physical, virtual and applicative - create a topology tree with the > Relations between the different entities in all layers, and perform > alarm analysis based on this

Re: [openstack-dev] [Heat] get_reality implementation: default values, specified in config files

Hm... It's sounds reasonable, I will think about it. 2015-12-03 15:37 GMT+03:00 Thomas Herve : > > > On Thu, Dec 3, 2015 at 1:00 PM, Peter Razumovsky > wrote: > >> >> Hello! >> >> During get_reality implementation next problem raised: if I don't

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

Igor, BTW, Fuel UI is Javascript CTI -compliant, so we can also start moving UI tests (at least linting and unit tests) from Fuel CI. But I think this should be done after moving Fuel UI to a separate repo for

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

Andrey I think this request is about updating RPM version of erlang which relates only to master node here. On Thu, Dec 3, 2015 at 3:48 PM, Andrey Sledzinskiy < asledzins...@mirantis.com> wrote: > Hi everybody, > please, note that we faced next issue [0] during 7.0-MU1 testing and one > of the

Re: [openstack-dev] [FUEL] FFE request for erlang and rabbitmq-server packaged for centos7

Hello! Please note that we already have updated packages for centos7 as follows: erlang=R16B03, rabbitmq-server=3.5.5 I'm just aware of version mismatch between ubuntu and centos in this case. I have already prepared packages for centos7. We could merge it in FFE time frame for centos7. AFAIK

Re: [openstack-dev] [puppet] Config support for oslo.config.cfg.MultiStrOpt

For puppetlabs-inifile that’s a bigger question. For our purposes the answer is “whatever ConfigParser does”. On Wed, Dec 2, 2015 at 10:32 PM, Cody Herriges wrote: > Martin, > > I see no reason this shouldn't just be pushed into puppetlabs-inifile. I > can't actually find a

Re: [openstack-dev] [cloudkitty] Remove inactive contributors from cloudkitty-core

+1 -- Guillaume Espanel Objectif Libre www.objectif-libre.com Infrastructure et Formations Linux Le 2015-12-03 14:45, Stéphane Albert a écrit : Hi, We didn't get your opinion Guillaume, are you approving it? Cheers - Forwarded message from Stéphane Albert

Re: [openstack-dev] Documentation containing external resource links & privacy breaches

> On 3 Dec 2015, at 13:37, Thomas Goirand wrote: > I've filed a bug against our docs theme, but it was marked as wontfix, > and the patch which I started, was reviewed negatively. I've been told > that we use Google Analytics for the openstack.org site, which I don't > think is

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi Julien, > From: Julien Danjou [mailto:jul...@danjou.info] > Sent: Thursday, December 03, 2015 10:53 AM > > On Thu, Dec 03 2015, AFEK, Ifat (Ifat) wrote: > > > Another question is our need to get alarms from other sources, like > > Nagios, zabbix, ganglia, etc. We thought that Vitrage would

[openstack-dev] [tripleo] stable/liberty branches are open

All, After quite a long battle, the stable/liberty CI is now working, as of this patch: https://review.openstack.org/#/c/247694/ We still need to verify that CI works properly on all other repos, because we had to go ahead and land what was ahead of that patch in the queue to reach a working

Re: [openstack-dev] [heat][tripleo] User Initiated Rollback

On Wed, 2015-12-02 at 16:02 +, Steven Hardy wrote: > So, chatting with Giulio today about https://bugs.launchpad.net/heat/ > +bug/1521944 > has be thinking about $subject. > > The root case of that issue is essentially a corner case of a stack- > update, > combined with some coupling within

Re: [openstack-dev] [ceilometer][aodh][vitrage] Raising custom alarms in AODH

Hi Ryota, > From: Ryota Mibu [mailto:r-m...@cq.jp.nec.com] > > > > Let me see if I got this right: are you suggesting that we create > > on-the-fly alarm definitions with no alarm_actions, for every deduced > alarm that we want to raise? And this will spare us the extra alarm > evaluation in

Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility

On 12/03/2015 11:21 AM, Evgeniy L wrote: > Hi, > > During Fuel master migration to CentOS7 there was found a problem that tests > get failed [0] for python2.6 > > As far as I can see it's a common practise to drop python2.6 > compatibility [1], > shouldn't we switch tests to work with python2.7

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 07:58, Ihar Hrachyshka wrote: > Armando M. wrote: > > Hi neutrinos, >> >> It's been a couple of months that the Bug deputy process has been in >> place [1,2]. Since the beginning of Mitaka we have collected the following >>

[openstack-dev] [glance] Auth_version from 'old style' URLs in the database

Hi, Currently glance will use an auth_url if in the database. Eg. 10.0.0.8:5000/v2.0 However glance currently takes the auth_version from the config files. Therefore this can lead to a mismatch of keystone version to be used between the url and the config files. This is problematic due to a

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

On 3 December 2015 at 08:33, Ihar Hrachyshka wrote: > Akihiro Motoki wrote: > > Hi, >> >> python-neutronclient still has XML support of Neutron API. >> I would like to discuss when we drop XML support in neutronclient. >> >> Neutron API XML suppoort was

Re: [openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

+1 Quoting Monty Taylor (2015-12-03 17:44:13) > Hey all, > > I'd like to propose that we include Morgan Fainberg as core on > os-client-config. He's in the over/under on matching other active > reviewers on the project, and he's got a good understanding of the > related problem space. Also, he's

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

I would love TripleO support on this topic On 12/03/2015 11:07 AM, arkady_kanev...@dell.com wrote: > Emilien, > > So what is the statement we (OpenStack) wants to provide about UI for OOO? AFIK, Tuskar won't be continued to be the TripleO UI but I might have misunderstood something. > If we

Re: [openstack-dev] [ironic] specs process for ironic-inspector

Hi Dmitry, should we also configure Launchpad to have blueprints references there (for release/milestone targeting etc)? Or is it not needed? Cheers, On Thu, Dec 3, 2015 at 4:00 PM Dmitry Tantsur wrote: > FYI: the process is in effect now. > > Please submit specs to >

Re: [openstack-dev] [Neutron][TaaS] Query regarding TaaS API

Hi Reedip, I believe TaaS API will go through a round of reviews when the spec is introduced. It will be good to discuss these points there. Fawad Khaliq On Wed, Nov 25, 2015 at 12:45 PM, reedip banerjee wrote: > Dear Members of Neutron-TaaS community, > I have a few

Re: [openstack-dev] [puppet] [tripleo] stop maintaining puppet-tuskar

Emilien, So what is the statement we (OpenStack) wants to provide about UI for OOO? If we will not provide it people outside our community and compatitors to OpenStack will fill the void. Thanks, Arkady -Original Message- From: Emilien Macchi [mailto:emil...@redhat.com] Sent: Wednesday,

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

On Thu, Dec 3, 2015 at 7:59 AM, Akihiro Motoki wrote: > Hi, > > python-neutronclient still has XML support of Neutron API. > I would like to discuss when we drop XML support in neutronclient. > > Neutron API XML suppoort was marked as deprecated in Icehouse and Juno > and was

[Openstack] Swift storage policies by account

Hi, I have multiple nodes of Swift and create some storage policies based on storage types and zones of nodes. I would like to know if it's possible to have one storage policy for each account? Or, for instance, if it's possible to define one default storage policy for one account? Regards,

Re: [openstack-dev] [nova] What things do we want to get into a python-novaclient 3.0 release?

On 11/20/2015 10:37 AM, Matt Riedemann wrote: On 11/20/2015 10:20 AM, Matt Riedemann wrote: On 11/20/2015 3:48 AM, Matthew Booth wrote: I wrote this a while back, which implements 'migrate everything off this compute host' in the most robust manner I could come up with using only the

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

I'm ok with that. The current core group is small and the project is critical enough to have them as backup. Ghe Rivero Quoting Monty Taylor (2015-12-03 17:50:17) > Hey all, > > os-client-config is now in the critical path for Infra's Nodepool, > meaning that there are some places where a bug

Re: [openstack-dev] [Neutron] Bug deputy process

On 2 December 2015 at 17:38, Sean M. Collins wrote: > I was not a deputy - but I had been subscribed to launchpad bugs for > years, but had a procmail filter set so it went into a folder that prior > to this new initiative, had remained unread for years. As part of this > new

Re: [openstack-dev] [neutron][all] when can we drop XML support in neutronclient? Now?

Akihiro Motoki wrote: Hi, python-neutronclient still has XML support of Neutron API. I would like to discuss when we drop XML support in neutronclient. Neutron API XML suppoort was marked as deprecated in Icehouse and Juno and was dropped in Kilo. Juno is now EOL and we

Re: [openstack-dev] [Sender Auth Failure] Re: [neutron] How could an L2 agent extension access agent methods ?

Ihar, This is brilliant. The complexity of doing graceful CRUD on the OVS flow table especially when other features are active is so complex, that abstracting the management of it into functionality optimized for that task is an incredibly good idea, especially for those of us like me who are

Re: [openstack-dev] [Fuel] CentOS7: merge freeze announcement

All, Just an update: we successfully passed *Decision point 3* in Centos7 merge plan [1], QA didn't find significant regressions after yesterday's merge party. The latest SWARM pass rate - 73% so we decided to proceed with merging CentOS7 commits on Fri Dec 4. Please note that any other commits

Re: [openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

Sounds like a great idea. On Thu, Dec 3, 2015 at 9:50 AM, Monty Taylor wrote: > Hey all, > > os-client-config is now in the critical path for Infra's Nodepool, meaning > that there are some places where a bug surfacing in it can take down the > entire CI infrastructure.

Re: [openstack-dev] [Neutron] Bug deputy process

On 3 December 2015 at 01:42, Rossella Sblendido wrote: > Hi Armando, > > On 12/02/2015 07:49 PM, Armando M. wrote: > >> Hi neutrinos, >> >> It's been a couple of months that the Bug deputy process has been in >> place [1,2]. Since the beginning of Mitaka we have collected

[Openstack] OpenStack Ironic does not honor clean steps (CVE-2015-7514)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === OpenStack Ironic does not honor clean steps === :Date: December 03, 2015 :CVE: CVE-2015-7514 Affects ~~~ - - Ironic: >= 4.2.0, <= 4.2.1 Description

[openstack-dev] [os-client-config] Proposing Morgan Fainberg for core

Hey all, I'd like to propose that we include Morgan Fainberg as core on os-client-config. He's in the over/under on matching other active reviewers on the project, and he's got a good understanding of the related problem space. Also, he's interested and active, which for a low-volume project

[openstack-dev] [os-client-config][infra] Proposing adding infra-core to core

Hey all, os-client-config is now in the critical path for Infra's Nodepool, meaning that there are some places where a bug surfacing in it can take down the entire CI infrastructure. Infra also uses many more of the advanced features in clouds.yaml than most other people, so the surface area

[openstack-dev] [all] making project_id optional in API URLs

For folks that don't know, we've got an effort under way to look at some of what's happened with the service catalogue, how it's organically grown, and do some pruning and tuning to make sure it's going to support what we want to do with OpenStack for the next 5 years (wiki page to dive deeper

[openstack-dev] [reno] using 'releasenotes' directive in documents for released tarball (without git info)

Hi, python-neutronclient recently added reno support and I added the reno directive " . release-notes::" to the neutronclient documentation. As a result, this prevents users from building the documentation from released tarballs using 'python setup.py build_sphinx' because the reno module expects

Re: [Openstack-operators] Cinder V1 endpoints

Yes, that appears to be a documentation error. - jlk On Thu, Dec 3, 2015 at 7:33 AM, Salman Toor wrote: > Hi, > > In the following link of Kilo document the cinder V1 endpoints have v2 in > it. > > >

Re: [openstack-dev] [Neutron] Bug deputy process

Armando M. wrote: Hi neutrinos, It's been a couple of months that the Bug deputy process has been in place [1,2]. Since the beginning of Mitaka we have collected the following statistics (for neutron and neutronclient): Total bug reports: 373 • Fix committed:

Re: [openstack-dev] Looking to contribute

Lisa Jenkins wrote on 11/02/2015 08:06:57 PM: > From: Lisa Jenkins > To: openstack-dev@lists.openstack.org > Date: 11/02/2015 08:11 PM > Subject: [openstack-dev] Looking to contribute > > Hi new dev looking to contribute and am open to anything. Which

Re: [openstack-dev] [Neutron] Bug deputy process

On 2 December 2015 at 11:02, Salvatore Orlando wrote: > I only have some historical, anecdotal, and rapidly waning memory of > previous releases. > Nevertheless my feeling is that the process has been a success so far. > In past times it would not have been a surprise if

[openstack-dev] [nova] Testing concerns around boot from UEFI spec

The boot from UEFI spec [1] is stalled a bit on testing concerns. I've asked that there is integration testing (either upstream or Intel hosts a 3rd party job for it), or we log a warning when it's used saying it's untested and therefore considered experimental. I think we also want to point

Re: [openstack-dev] [horizon]

Looks great. What is the estimated date / release for this feature to be delivered? On Thu, Dec 3, 2015 at 4:40 PM, Timur Sufiev wrote: > Please take a look at > https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload > > On Thu, Dec 3, 2015 at

Re: [openstack-dev] [Neutron] Scaling our testing needs

Armando M. wrote: Hi Neutrinos, I would like to share a proposal with you on how we could scale our ever-growing testing needs, and at the same time, provide guidance to the developers who care about the quality of the work they produce, and how they can protect it

  1   2   >