Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

On 1/14/2016 9:42 AM, Dan Smith wrote: It is however not ideal when a deployment is set up such that multiattach will always fail because a hypervisor is in use which doesn't support it. An immediate solution would be to add a policy so a deployer could disallow it that way which would

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On 01/14/2016 11:35 PM, Yuriy Taraday wrote: > > > On Thu, Jan 14, 2016 at 5:48 PM Jeremy Stanley > wrote: > > On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: > [...] > > Is there any plan to add Python 3.5 to infra? > >

[openstack-dev] [Fuel] nova-network removal

Folks, We have a request on review which prohibits creating new envs with nova-network: https://review.openstack.org/#/c/261229/ We're 3 weeks away from HCF, and I think this is too late for such a change. What do you think? Should we proceed and remove nova-network support in 8.0, which is

[openstack-dev] [defcore] Determine latest set of tests for a given release

Hi All, Whats the most reliable way to determine the latest set of required defcore tests for a given release? For example, I would currently use 2015.07/2015.07.required.txt but I don't want to have to update that url each time there is a defcore release. I could parse 20*.json in the root of

Re: [openstack-dev] [defcore] Determine latest set of tests for a given release

[+defcore-committee] This depends a little on what your objective is. If you’re looking for the tests that a product must pass today if it wants an OpenStack Powered logo/trademark agreement, you’ll want to look at either of the two most recently-approved DefCore Guidelines (currently 2015.5

[openstack-dev] [Nova] Nova midcycle list of attendees

I have created a list of attendees for the Nova midcycle here: https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprintAttendees Obviously I can't put anyone's name on it for privacy reasons. If are attending and you would like to let others know when you will be around you might like to add

Re: [openstack-dev] [infra][all] "openstack-meeting-cp" == "openstack-meeting-5"?

Tony Breeds wrote on 01/13/2016 11:32:24 PM: > From: Tony Breeds > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 01/13/2016 11:33 PM > Subject: Re: [openstack-dev] [infra][all]

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Thanks for your insight guys! I agree with Oleg, I will see what I can do to make this work this way. About hardlinks - wouldn't it be better to use symlinks? This way we don't occupy more space than necessary, and we can link to files and directories that are in other block device than /var.

Re: [openstack-dev] OpenStack-Announce List

LOL Tom :) -- Dims On Thu, Jan 14, 2016 at 2:32 AM, Tom Fifield wrote: > On 14/01/16 15:22, Andreas Jaeger wrote: >> >> On 2016-01-14 08:13, Tom Fifield wrote: >>> >>> So, I'm prompted by another 20 oslo release emails to dredge up this >>> thread :) >>> >>> There appears to

Re: [openstack-dev] [keystone][security] New BP for anti brute force in keystone

On Wed, Jan 13 2016, Morgan Fainberg wrote: > A standard method of rate limiting for OpenStack services would be a good > thing to figure out. Apache used as a daemon for WSGI application (e.g. like we do by default in devstack) has support for rate limit for decades – see mod_ratelimit for

Re: [openstack-dev] [Keystone][Neutron][Nova][devstack] Keystone v3 with "old" clients

On 01/12/2016 02:10 PM, Smigiel, Dariusz wrote: Hello, I'm trying to gather all the info necessary to migrate to keystone v3 in Neutron. When I've started to looking through possible problems with clients, it occurred that 'neutron' and 'nova' clients do not want to operate with Keystone v3.

[openstack-dev] [tricircle] move to stateless design in master branch.

Hello, As the stateless design in the experiment branch has a quite positive feedback, the stateless design is moved from the experiment branch to the master branch. You can try it through Devstack: https://github.com/openstack/tricircle If you find bug, please feel free to report it at

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On Wed, Jan 13 2016, Thomas Goirand wrote: > In other words, any Python 3.5 problem in Olso, clients and so on will > be considered a Debian RC bug and shall be addressed ASAP there. I know there are problems with a few of the Python 3 supported OpenStack projects. Since we can't gate on Python

Re: [openstack-dev] [Keystone][Neutron][Nova][devstack] Keystone v3 with "old" clients

devstack creates /etc/openstack/clouds.yaml (os-client-config configuraiton files) which specifies to use keystone v3. neutronclient supports os-client-config and keystoneauth which handles the difference of keystone API. Note that clouds.yaml is very convenient way to use OpenStack CLI [1]. As

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

I think Tony would be a valuable addition to the team. +1 Michael On 14 Jan 2016 7:59 AM, "Matt Riedemann" wrote: > I'm formally proposing that the nova-stable-maint team [1] adds Tony > Breeds to the core team. > > I don't have a way to track review status on

Re: [openstack-dev] [neutron][L3] Wrong fail over of HA-Router

Here you have an information about that bug - it's a known issue in Keepalived v.1.2.7 https://bugs.launchpad.net/neutron/+bug/1497272 Regards, Lubosz On 01/14/2016 02:27 AM, Ikuo Kumagai wrote: Hi All Could you give me some advice for our problem? We use Neutron L3-HA. When I

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hey Maceij - > About hardlinks - wouldn't it be better to use symlinks? > This way we don't occupy more space than necessary AFAIK, hardlinks won't occupy much space. They are the links, after all. :) As for symlinks, I'm afraid shotgun (and fabric underneath) won't resolve them and links are

Re: [openstack-dev] [nova][neutron][os-vif] os-vif core review team membership

On Wed, Jan 13, 2016 at 10:59 AM, Daniel P. Berrange wrote: > On Tue, Jan 12, 2016 at 10:28:49PM +, Mooney, Sean K wrote: >> > -Original Message- >> > From: Moshe Levi [mailto:mosh...@mellanox.com] >> > Sent: Tuesday, January 12, 2016 4:23 PM >> > To: Russell

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Igor, I meant that symlinks also give us the benefit of not using additional space (just as hardlinks do) while being able to link to files from different filesystems. Also, as Barłomiej pointed out the `h` switch for tar should do the trick [1]. Cheers, Maciej [1]

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On Wed, Jan 13, 2016 at 1:15 PM, Steven Dake (stdake) wrote: > Hey folks, > > I'd like to have a mailing list discussion about logistics of the ELKSTACK > solution that Alicja has sorted out vs the Heka implementation that Eric is > proposing. > > My take on that is Eric wants

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Igor, I took a glance on Maciej's patch and it adds a switch to tar command to make it follow symbolic links, so it looks good to me. Bartłomiej On Thu, Jan 14, 2016 at 10:39 AM, Igor Kalnitsky wrote: > Hey Maceij - > > > About hardlinks - wouldn't it be better to use

Re: [openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

On Wed, Jan 13, 2016 at 1:27 PM, Steven Dake (stdake) wrote: > Eric, Hi Steven > > Apologies for top post, not really sure where in this thread to post this > list of questions as its sort of a change in topic so I changed the > subject line :) > > 1. > Somewhere I read when

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

Matt Riedemann wrote: I'm formally proposing that the nova-stable-maint team [1] adds Tony Breeds to the core team. I don't have a way to track review status on stable branches, but there are review numbers from gerrit for stable/liberty [2] and stable/kilo

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

> I took a glance on Maciej's patch and it adds a switch to tar command > to make it follow symbolic links Yeah, that should work. Except one thing - we previously had fqdn -> ipaddr links in snapshots. So now they will be resolved into full copy? > I meant that symlinks also give us the benefit

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

On Wed, Jan 13, 2016 at 02:16:44PM -0500, Dan Prince wrote: > On Tue, 2016-01-12 at 20:47 +, Steven Hardy wrote: > > Hi all, > > > > I've noticed that we have a fairly large number of unused parameters > > in > > t-h-t, some of which are marked deprecated, some aren't. > > > > Since we moved

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Igor, I will investigate this, thanks! Artem, I guess that if we have an untrusted user on master node, he could just put something he wants to be in the snapshot in /var/log without having to time the attack carefully with tar execution. I want to use links for directories, this saves me the

Re: [openstack-dev] [Keystone][Neutron][Nova][devstack] Keystone v3 with "old" clients

Hi, Did exporting the variables solve your problem? I'm working on improving the support of v3 in devstack, like the openrc you've mentioned. Em qui, 14 de jan de 2016 às 06:50, Akihiro Motoki escreveu: > devstack creates /etc/openstack/clouds.yaml (os-client-config >

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 14/01/16 12:01, Davanum Srinivas wrote: > Neil, > > The global requirements upper-constraints.txt do not cover neutron > unit test targets. So the unit tests pick up latest from pypi. I'm afraid I don't understand how that's related to my question below. Could you explain further? It seems

Re: [openstack-dev] [all] "Upstream Development" track at the Austin OpenStack Summit

On 01/13/2016 05:58 AM, Thierry Carrez wrote: > Hi everyone, > > As you may have already noticed in the CFP[1], in Austin for the first > time we'll have a conference track clearly targeted to upstream > OpenStack developers (us all on this mailing-list). It will run on the > Monday, /before/ the

Re: [openstack-dev] Further closing the holes that let gate breakage happen

Neil, Apologies. you are right, test_bash_completion is a unit test. and neutron failure is in "gate-neutron-python27-constraints". so yes, that was broken by the change to upper-constraints.txt. https://review.openstack.org/#/c/266042/ is a valid request as it has a g-r change and a u-c change

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/14/2016 12:38 AM, Matthew Treinish wrote: > On Wed, Jan 13, 2016 at 10:47:21PM +, Sean M. Collins wrote: >> On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: >>> One of the ideas that I have been thinking about over the last month or two >>> is do we >>> Want to create a

Re: [openstack-dev] Further closing the holes that let gate breakage happen

On 13/01/16 19:27, Carl Baldwin wrote: > Hi, > > I was looking at the most recent gate breakage in Neutron [1], fixed > by [2]. This gate breakage was held off for some time by the > upper-constraints.txt file. This is great progress and I applaud it. > I'll continue to cheer on this effort. >

Re: [openstack-dev] Further closing the holes that let gate breakage happen

Neil, The global requirements upper-constraints.txt do not cover neutron unit test targets. So the unit tests pick up latest from pypi. -- Dims On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram wrote: > On 13/01/16 19:27, Carl Baldwin wrote: >> Hi, >> >> I was looking

Re: [openstack-dev] [Neutron] Gate failure

UPD both fixes merged, should now be safe to recheck neutron patches. Doug Wiegley wrote: This fix failed to merge, due to a new regression in how another job is using dib. Here's a non voting patch for that, until it gets debugged:

Re: [openstack-dev] [Fuel] Diagnostic snapshot generation is broken due to lack of disk space

Hi, using symlinks is a bit dangerous, here is a quote from the man you mentioned [0]: > The`--dereference'option is unsafe if an untrusted user can modify directories while|tar|is running. Hard links usage is much safer, because you can't use them for directories. But at the same time

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

On Wed, Jan 13, 2016 at 04:41:28AM -0500, Tzu-Mainn Chen wrote: > Hey all, > > I realize now from the title of the other TripleO/Mistral thread [1] that > the discussion there may have gotten confused. I think using Mistral for > TripleO processes that are obviously workflows - stack deployment,

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

On 28.12.2015 10:12, Bogdan Dobrelya wrote: > On 23.12.2015 18:50, Matthew Mosesohn wrote: >> I agree. As far as I remember, rabbit needs fqdns to work and map >> correctly. I think it means we should disable the ability to move the >> internal messaging network role in order to fix this bug until

Re: [openstack-dev] [Monasca] Enabling Graphana GUI from Horizon

Thanks. I can able to see the 'Monitoring' tab in the Horizon UI. However not able to launch the Monasca UI (Graphana). When trying to launch it, getting a "Page not found error:" : Using the URLconf defined in openstack_dashboard.urls, Django tried these URL patterns, in this order: 1. ^$

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/13/2016 11:51 PM, Tony Breeds wrote: > The challenge for you guys is the kernel side of things but if I > understood correctly you can get the kenrel module from the ovs > source tree and just compile it against the stock ubuntu kernel > (assuming the kernel devel headers are available) is

Re: [openstack-dev] [fuel] RabbitMQ in dedicated network

+1 to Bogdan here. On Thu, Jan 14, 2016 at 4:27 PM, Bogdan Dobrelya wrote: > On 28.12.2015 10:12, Bogdan Dobrelya wrote: > > On 23.12.2015 18:50, Matthew Mosesohn wrote: > >> I agree. As far as I remember, rabbit needs fqdns to work and map > >> correctly. I think it

[openstack-dev] [glance] FFE for "Multi-tenant Swift store service token support"

Hi, I'd like to request an exception for this spec: https://review.openstack.org/#/c/170564/ -Stuart __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:

Re: [openstack-dev] [nova][stable] Proposal to add Tony Breeds to nova-stable-maint

Michael Still wrote: I think Tony would be a valuable addition to the team. I think Tony would be a valuable addition to /any/ team. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [glance] allow a ranking mechanism for glance-api to order image locations

On 14/01/16 11:07 +1100, Jake Yip wrote: Hi all, I've recently ran across a constraint in glance-api while working with image locations. In essence, there is no way to customize ordering of image-locations other than the default location strategies, namely location_order and store_type [0]. It

Re: [openstack-dev] [openstack-ansible][security] Should the playbook stop on certain tasks?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/13/2016 02:59 PM, Clark, Robert Graham wrote: > I’m pretty new to openstack-ansible-security but based on my use cases which > are as much > About using this for verification as they are for building secure boxes my > preference > would be

Re: [openstack-dev] [Keystone][Neutron][Nova][devstack] Keystone v3 with "old" clients

Hey, Thanks for responses. Michal your suggestion helped solve my problem. Akihiro, thanks for this info. Didn't know about os-client but it seems to be very powerful. Great tool! Henrique, yes. Right now I have no problems with keystone v3. Best regards, Dariusz (dasm) Smigiel Intel

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

On 1/14/2016 9:42 AM, Dan Smith wrote: It is however not ideal when a deployment is set up such that multiattach will always fail because a hypervisor is in use which doesn't support it. An immediate solution would be to add a policy so a deployer could disallow it that way which would

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

Sean M. Collins wrote: On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote: One of the ideas that I have been thinking about over the last month or two is do we Want to create a dedicated library file in devstack to support compilation and installation Of ovs.

Re: [openstack-dev] [Bareon][Fuel] Dynamic allocation algorithm

Hi, In addition I've generated several examples in order to show how current prototype allocates the volumes [0]. Thanks, [0] http://bareon-allocator.readthedocs.org/en/latest/examples.html On Wed, Jan 13, 2016 at 2:14 PM, Evgeniy L wrote: > Hi Artur, > > You are correct,

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On 01/14/2016 10:47 PM, Jeremy Stanley wrote: > On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: > [...] >> Is there any plan to add Python 3.5 to infra? > > I expect we'll end up with it shortly after Ubuntu 16.04 LTS > releases in a few months (does anybody know for sure what its >

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

When using the native Docker tooling, the Docker daemon controls the UUID of the container, not Magnum. -- Kyle From: Ryan Brown Sent: Wednesday, January 13, 2016 3:16 PM To: openstack-dev@lists.openstack.org Subject: Re:

Re: [openstack-dev] [ceilometer] ceilometer meter-list output is empty

hi, please ensure you are running latest code (as you seem to want master) you are running into https://review.openstack.org/#/q/I4765b3b9627983a245aa5521a85ad89e83ab8551 On 14/01/2016 12:10 AM, lichen.hangzhou wrote: Hi, I have installed a devstack environment with ceilometer enabled:

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

On 01/14/2016 11:45 AM, Ronald Bradford wrote: Presently the oslo.config Opt class has the attributes deprecated_for_removal and deprecated_reason [1] I would like to propose that we use deprecated_reason (at a minimum) to detail in what release an option was deprecated in, and what release it

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

This presumes a model where Magnum is in complete control of the IDs of individual containers. How does this work with the Docker daemon? > In Rest API, you can set the “uuid” field in the json request body (this is > not supported in CLI, but it is an easy add).​ In the Rest API for Magnum

Re: [openstack-dev] [Nova] Nova midcycle list of attendees

On 01/14/2016 12:38 PM, Murray, Paul (HP Cloud) wrote: > I have created a list of attendees for the Nova midcycle here: > https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprintAttendees > > Obviously I can't put anyone's name on it for privacy reasons. What privacy reasons? Every other

[openstack-dev] [app-catalog] Automating some aspects of catalog maintenance

While we are looking forward to implementing an API based on Glare, I think it would be nice to have a few aspects of catalog maintenance be automated. For instance discovering and removingt/agging assets with dead links, updating the hash for assets that change frequently or exposing when an

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

On Thu, Jan 14, 2016 at 11:58 AM, Jay Pipes wrote: > On 01/14/2016 11:45 AM, Ronald Bradford wrote: >> >> Presently the oslo.config Opt class has the attributes >> deprecated_for_removal and deprecated_reason [1] >> >> I would like to propose that we use deprecated_reason (at

[openstack-dev] [app-catalog] App Catalog IRC meeting minutes - 1/14/2016

This morning we had a quick status update regarding some automation within the catalog followed by a good chat about adding Mistral workflow templates to the catalog. We're going to work out what metadata the assets will need to include and start discussing the changes we'll need to make to the

Re: [openstack-dev] [defcore] Determine latest set of tests for a given release

Hi Mark, Thanks for your useful and timely response. I did look at the refstack client, but it seems that it requires a test list url as input, I was wondering how to programmatically get the appropriate test list url. It sounds like there isn't a single url that points to an index of defcore

Re: [openstack-dev] [neutron] gate-neutron-dsvm-api failures

On 1/14/16, 3:04 PM, "Brian Haley" wrote: >On 01/14/2016 05:42 PM, John Davidge (jodavidg) wrote: >> The >>neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTe >>stJSON >> test has been consistently failing for patch >>

[openstack-dev] [stable] Call for testing: 2015.1.3 candidate tarballs

Hi all, We are scheduled to release the next point release of stable Kilo (2015.1.3). The current candidates for release are: Ceilometer, Cinder, Glance, Heat, Horizon, Ironic, Keystone, Neutron, Neutron-lbaas, Neutron-vpnaas, Nova and Sahara releases on Thursday Jan 21st 2016. The current open

Re: [openstack-dev] [kolla] Can Heka solve all the deficiencies in the current rsyslog implementation: was Re: [kolla] Introduction of Heka in Kolla

Eric, Comments inline. On 1/14/16, 3:31 AM, "Eric LEMOINE" wrote: >On Wed, Jan 13, 2016 at 1:27 PM, Steven Dake (stdake) >wrote: >> Eric, > > >Hi Steven Feel free to call me Steve > > >> >> Apologies for top post, not really sure where in this

Re: [openstack-dev] [Nova] Nova midcycle list of attendees

Another issue is some people may not want to share where they are staying or their arrival/departure details. I also appreciated Paul's tactfulness here :) Thanks Paul for putting that page up! I particularly appreciate the transportation column as I've heard transit in that area is a bit

Re: [openstack-dev] [neutron] gate-neutron-dsvm-api failures

On 01/14/2016 05:42 PM, John Davidge (jodavidg) wrote: The neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON test has been consistently failing for patch https://review.openstack.org/#/c/258754/ and I don’t see how they can be related. This patch has been trying to

[openstack-dev] [stable] kilo 2015.1.3 freeze exception request for cve fixes

We should get this series in for nova in the kilo 2015.1.3 release: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:bug/1524274 -- Thanks, Matt Riedemann __ OpenStack

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Thu, Jan 14, 2016 at 10:00:03AM CST, Ihar Hrachyshka wrote: > Currently, devstack plugin has code for: > * qos > * sr-iov > * l2 agent extensions > * flavors Right - and from the start on the review that introduced the Neutron devstack plugin in the neutron tree, as well on IRC I advocated

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

Excerpts from Jay Pipes's message of 2016-01-14 11:58:13 -0500: > On 01/14/2016 11:45 AM, Ronald Bradford wrote: > > Presently the oslo.config Opt class has the attributes > > deprecated_for_removal and deprecated_reason [1] > > > > I would like to propose that we use deprecated_reason (at a

[openstack-dev] What's Up, Doc? 15 January

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everyone, Welcome to 2016! A short newsletter this week as I get my feet back under me after my vacation. I hope you all had a wonderful holiday period, and got some well-earned down time. I'm looking forward to working hard with you all over

Re: [openstack-dev] [neutron] gate-neutron-dsvm-api failures

Looks like this is exposing a legitimate bug: https://bugs.launchpad.net/neutron/+bug/1534447 On Thu, Jan 14, 2016 at 5:23 PM, John Davidge (jodavidg) wrote: > On 1/14/16, 3:04 PM, "Brian Haley" wrote: > > > >On 01/14/2016 05:42 PM, John Davidge

[openstack-dev] [Nova] Get-validserver-state default policy

This API change was agreed is the spec review to be "rule: admin_or_owner", but during code review "rule: admin_api" was also wanted. Link to spec to see details what this is about (https://review.openstack.org/192246/):

[openstack-dev] [Horizon] Email as User Name on the Horizon login page

I've run into a weird issue with the Liberty release of Horizon. For our deployment we enforce emails as usernames, and thus for Horizon we used to have "User Name" on the login page replaced with "Email". This used to be a straightforward change in the html template file, and with the

[openstack-dev] [cinder] Should we fix XML request issues?

Hi Devs, I have come across a few 500 response issues while sending request body as XML to cinder service. For example: -- openstack@openstack-136:/opt/stack/cinder$ curl -i -X PUT -H "X-Auth-Token: 79e6f8f529d2494b81dbd1a6ea5e077d" -H "Accept: application/xml"

[openstack-dev] [neutron] gate-neutron-dsvm-api failures

The neutron.tests.api.admin.test_floating_ips_admin_actions.FloatingIPAdminTestJSON test has been consistently failing for patch https://review.openstack.org/#/c/258754/ and I don't see how they can be related. This patch has been trying to merge for a month. This test seems to be

Re: [openstack-dev] [Nova] Nova midcycle list of attendees

On Jan 14, 2016 3:43 PM, "Anita Kuno" wrote: > > On 01/14/2016 12:38 PM, Murray, Paul (HP Cloud) wrote: > > I have created a list of attendees for the Nova midcycle here: https://wiki.openstack.org/wiki/Sprints/NovaMitakaSprintAttendees > > > > Obviously I can't put anyone's

[openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team

Hi fellow core reviewers, Harm joined Kolla early on with great enthusiasm and did a bang-up job for several months working on Kolla. We voted unanimously to add him to the core team. Over the last 6 months Harm hasn't really made much contribution to Kolla. I have spoken to him about it in

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 2016-01-14 22:14:09 + (+), Sean M. Collins wrote: [...] > The problem we have is - most operators are using Ubuntu according to > the user survey. Most likely they are using LTS releases. We already get > flack for our pace of releases and our release lifecycle duration, so > if we were

[openstack-dev] Long description of oslo.privsep

Hi, Lucky I have written, in the cookie-butter repo: Please feel here a long description which must be at least 3 lines wrapped on 80 cols, so that distribution package maintainers can use it in their packages. Note that this is a hard requirement. Because without it, we could see stuff like

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

Hi, What are the issues? Is there a list of issues somewhere? Victor Le 13/01/2016 03:07, Thomas Goirand a écrit : Hi, Just a quick notice for those not following developments in Debian. Python 3.5 is now the default Python 3 interpreter in Debian Unstable, and when the transition will be

Re: [openstack-dev] [Nova] Get-validserver-state default policy

On 01/15/2016 01:50 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote: This API change was agreed is the spec review to be “rule: admin_or_owner”, but during code review “rule: admin_api” was also wanted. Link to spec to see details what this is about (https://review.openstack.org/192246/):

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 01/14/2016 03:56 PM, Michał Jastrzębski wrote: On 14 January 2016 at 04:46, Eric LEMOINE wrote: On Wed, Jan 13, 2016 at 1:15 PM, Steven Dake (stdake) wrote: Hey folks, I'd like to have a mailing list discussion about logistics of the ELKSTACK

Re: [openstack-dev] [Nova] Get-validserver-state default policy

>-Original Message- >From: EXT Jay Pipes [mailto:jaypi...@gmail.com] >Sent: Friday, January 15, 2016 9:25 AM >To: openstack-dev@lists.openstack.org >Subject: Re: [openstack-dev] [Nova] Get-validserver-state default policy > >On 01/15/2016 01:50 AM, Juvonen, Tomi (Nokia - FI/Espoo) wrote:

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/14/2016 03:43 PM, Assaf Muller wrote: > On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant wrote: >> On 01/13/2016 11:51 PM, Tony Breeds wrote: >>> The challenge for you guys is the kernel side of things but if I >>> understood correctly you can get the kenrel module from

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Thu, Jan 14, 2016, at 01:07 PM, Russell Bryant wrote: > On 01/14/2016 03:43 PM, Assaf Muller wrote: > > On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant wrote: > >> On 01/13/2016 11:51 PM, Tony Breeds wrote: > >>> The challenge for you guys is the kernel side of things but

[openstack-dev] [release] Release countdown for week R-11, Jan 18-22, Mitaka-2 milestone

Focus - Next week is the second milestone for the Mitaka cycle. Major feature work should be making good progress or be re-evaluated to see whether it will really land this cycle. Release Actions --- Liaisons should submit tag requests to the openstack/releases repository for

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Thu, Jan 14, 2016 at 03:13:16PM CST, Clark Boylan wrote: > Forgive my ignorance, but if we are gating on OVS 2.0 that is because it > is what is shipped with the distros that we test on. Are we saying that > no one uses the distro provided OVS packages to run Neutron? If not what > are they

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Thu, Jan 14, 2016 at 09:30:03PM +, Sean M. Collins wrote: > On Thu, Jan 14, 2016 at 03:13:16PM CST, Clark Boylan wrote: > > Forgive my ignorance, but if we are gating on OVS 2.0 that is because it > > is what is shipped with the distros that we test on. Are we saying that > > no one uses

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On Thu, Jan 14, 2016 at 9:28 AM, Russell Bryant wrote: > On 01/13/2016 11:51 PM, Tony Breeds wrote: >> The challenge for you guys is the kernel side of things but if I >> understood correctly you can get the kenrel module from the ovs >> source tree and just compile it against

Re: [openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?

- Original Message - > On Wed, Jan 13, 2016 at 04:41:28AM -0500, Tzu-Mainn Chen wrote: > > Hey all, > > > > I realize now from the title of the other TripleO/Mistral thread [1] that > > the discussion there may have gotten confused. I think using Mistral for > > TripleO processes that

[openstack-dev] [cross-project] Cross-Project Specs and Your Project

Hello all! We've been discussing cross-project spec liaisons on the mailing list [1] and cross-project meeting [2][3] for a bit, and we're now stating the official responsibilities [4] of the group. The liaisons are reps of OpenStack projects to watch the cross-project spec repo [5] for things

[openstack-dev] [all][api] New API Guidelines Ready for Cross Project Review

hi all, The following API guideline is ready for cross project review. It will be merged on Jan. 21 if there is no further feedback. 1. Add description of pagination parameters https://review.openstack.org/#/c/190743 regards, mike

Re: [openstack-dev] [magnum] Nesting /containers resource under /bays

In short, the container IDs assigned by Magnum are independent of the container IDs assigned by Docker daemon. Magnum do the IDs mapping before doing a native API call. In particular, here is how it works. If users create a container through Magnum endpoint, Magnum will do the followings: 1.

[openstack-dev] you almost never need to change every repository

We've started seeing a lot of changes that tweak the same thing across many, many repositories. While it's good to have standardization, I think it's safe to say that if you find yourself making the same change to more than a few repositories at once, we should be looking for another way to have

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: [...] > Is there any plan to add Python 3.5 to infra? I expect we'll end up with it shortly after Ubuntu 16.04 LTS releases in a few months (does anybody know for sure what its default Python 3 is slated to be?). Otherwise if a debian-sid

[openstack-dev] [glance][artifacts] FFE for Glare specs

Hi, Unfortunately I skipped the "spec freeze exception week" due to a long holiday season, so I'd like to ask for the freeze exception for the following two specs now: *1. Add more implementation details to 'deprecate-v3-api'* [1] *2. Glare Public API *[2] Spec [1] is actually a patch adding

Re: [openstack-dev] [nova][cinder] How will nova advertise that volume multi-attach is supported?

On Wed, Jan 13, 2016, at 07:25 PM, Dan Smith wrote: > > While I don't think it's strictly required by the api change guidelines [3] > > I think the API interactions and behavior here feel different enough to > > warrant > > having a microversion. Ideally there should have been some versioning

Re: [openstack-dev] [kolla] Heka v ELK stack logistics

On 14 January 2016 at 04:46, Eric LEMOINE wrote: > On Wed, Jan 13, 2016 at 1:15 PM, Steven Dake (stdake) > wrote: >> Hey folks, >> >> I'd like to have a mailing list discussion about logistics of the ELKSTACK >> solution that Alicja has sorted out vs the

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 1/14/16 9:28 AM, Russell Bryant wrote: The consensus I'm picking up roughly is that for those working on the features, testing with source builds seems to be working fine. It's just not something anyone wants to gate the main Neutron repo with. That seems quite reasonable. If the features

[openstack-dev] [release][openstack] os-client-config release 1.14.0 (mitaka)

We are chuffed to announce the release of: os-client-config 1.14.0: OpenStack Client Configuation Library This release is part of the mitaka release series. With source available at: http://git.openstack.org/cgit/openstack/os-client-config With package available at:

[openstack-dev] [Oslo] Improving deprecated options identification and documentation

Presently the oslo.config Opt class has the attributes deprecated_for_removal and deprecated_reason [1] I would like to propose that we use deprecated_reason (at a minimum) to detail in what release an option was deprecated in, and what release it is then removed in. I see examples of

Re: [openstack-dev] [all] Python 3.5 is now the default Py3 in Debian Sid

On Thu, Jan 14, 2016 at 5:48 PM Jeremy Stanley wrote: > On 2016-01-14 09:47:52 +0100 (+0100), Julien Danjou wrote: > [...] > > Is there any plan to add Python 3.5 to infra? > > I expect we'll end up with it shortly after Ubuntu 16.04 LTS > releases in a few months (does

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

On 01/14/2016 04:32 PM, Ben Pfaff wrote: > On Thu, Jan 14, 2016 at 09:30:03PM +, Sean M. Collins wrote: >> On Thu, Jan 14, 2016 at 03:13:16PM CST, Clark Boylan wrote: >>> Forgive my ignorance, but if we are gating on OVS 2.0 that is because it >>> is what is shipped with the distros that we

  1   2   >