[openstack-dev] [Blazar] Anyone interested?

Hi All, The resource reservation topic pops up time to time on different forums to cover use cases in terms of both IT and NFV. The Blazar project was intended to address this need, but according to my knowledge due to earlier integration and other difficulties the work has been stopped. My qu

[openstack-dev] info in paste will be removed?

Folks, I would like to know whether info in http://paste.openstack.org will be removed or not. If it will be removed, I also would like to know a condition. Thanks in advance, Hisashi Osanai __ OpenStack Development Maili

Re: [openstack-dev] [Heat] convergence rally test results (so far)

Angus! it's Awesome! Thank you for the investigation. I had a talk with guys from Sahara team and we decided to start testing convergence with Sahara after L release. I suppose, that Murano can also join to this process. Also AFAIK Sahara team plan to create functional tests with Heat-engine. We

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

On 08/27/2015 09:38 PM, Ben Swartzlander wrote: Manila recently implemented microversions, copying the implementation from Nova. I really like the feature! However I noticed that it's legal for clients to transmit "latest" instead of a real version number. THIS IS A TERRIBLE IDEA! I recommend r

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

Dmitriy, New tests, that cover new functionality already know which API version they require. So, even in testing, it is not needed. All other existing tests do not require API update. So, I raise hand for restricting "latest". On Fri, Aug 28, 2015 at 10:20 AM, Dmitry Tantsur wrote: > On 08/27

Re: [openstack-dev] subunit2html location on images changing

On Thu, 27 Aug 2015, Chris Dent wrote: On Wed, 26 Aug 2015, Matthew Treinish wrote: http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n571 Is 'process_testr_artifacts' going to already be in scope for the hook script or will it be necessary to source functions.sh

Re: [openstack-dev] --detailed-description for OpenStack items

> -Original Message- > From: Matt Riedemann [mailto:[email protected]] > Sent: 28 August 2015 02:29 > To: [email protected] > Subject: Re: [openstack-dev] --detailed-description for OpenStack items > > > > On 8/27/2015 12:23 PM, Tim Bell wrote: > > Some project

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

On 08/28/2015 09:34 AM, Valeriy Ponomaryov wrote: Dmitriy, New tests, that cover new functionality already know which API version they require. So, even in testing, it is not needed. All other existing tests do not require API update. Yeah, but you can't be sure that your change does not break

Re: [openstack-dev] [Glance] upcoming glanceclient release

On 27/08/15 15:32 -0400, Nikhil Komawar wrote: As a part of our continued effort to make the v2 primary API and get people to consume it without confusion we are planning to move ahead with the client release (the release would set the default version of API to 2). There haven't been any major/m

Re: [openstack-dev] [fuel] Branching strategy vs feature freeze

Dmitry, Ruslan, Mike, I assume that we agreed on this short plan (thank you all and Thierry for cooperation). I fully support it. * Short FF: create stable branch couple of weeks after FF for upstream Fuel * Untie release schedule for upstream Fuel and MOS. This should be two separate schedules

Re: [openstack-dev] [Heat] convergence rally test results (so far)

Hi, great, it seems like migration to convergence could happen soon. How many times you were running each test case? Does time changing with number of iterations? Are you planning to test parallel stacks creation? Thanks. On Fri, Aug 28, 2015 at 10:17 AM, Sergey Kraynev wrote: > Angus! > > it

Re: [openstack-dev] --detailed-description for OpenStack items

On 27/08/15 18:35 +, Tim Bell wrote: That could be done but we'd need to establish an agreed name so that Horizon or the CLIs, for example, could filter based on description. "Give me all VMs with Ansys in the description". If we use properties, a consistent approach would be needed so the

Re: [openstack-dev] [nova] testing for setting the admin password via the libvirt driver

On Tue, Aug 25, 2015 at 09:14:33AM -0500, Matt Riedemann wrote: > Support to change the admin password on an instance via the libvirt driver > landed in liberty [1] but the hypervisor support matrix wasn't updated [2]. > There is a version restriction in the driver that it won't work unless > you'r

Re: [openstack-dev] [murano] Cloud Foundry service broker question

Ok, I belive we can take it in mind as possible resolution. The problem is that it will take it us too long, so we can discuss it while we will plan Mitaka development. However it's not a decision of the problem with service broker API for now. Nikolay Starodubtsev Software Engineer Mirantis I

Re: [openstack-dev] [murano] [dashboard] public package visibility in Package Definitions UX concern

My vote is for #1. If I remember the problem right it's the best solution. Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-08-20 13:16 GMT+03:00 Kirill Zaitsev : > On our latest irc meeting I raised a concern about public package > visibility. Here’s the c

Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability zones

> From: Ben Swartzlander [mailto:[email protected]] > Sent: Thursday, August 27, 2015 8:11 PM > To: OpenStack Development Mailing List (not for usage questions) > > On 08/27/2015 10:43 AM, Ivan Kolodyazhny wrote: > > > Hi, > > Looks like we need to be able to set AZ per backend.

Re: [openstack-dev] [Horizon] [Nova] [Cinder] Need to add selection of availability zone for new volume

Hi, If I recall correctly your Horizon-based solution won't be possible, because of how Nova's code works internally - it just passes Nova's AZ to Cinder API, without allowing to overwrite it. We're discussing this particular issue in another ML thread http://lists.openstack.org/pipermail/open

Re: [openstack-dev] [Heat] convergence rally test results (so far)

On Fri, Aug 28, 2015 at 6:35 PM Sergey Lukjanov wrote: > Hi, > > great, it seems like migration to convergence could happen soon. > > How many times you were running each test case? Does time changing with > number of iterations? Are you planning to test parallel stacks creation? > Given the tes

Re: [openstack-dev] [ironic] final release in Liberty cycle

Ruby Loo wrote: > Our first semver release, 4.0.0, was tagged this week but a few more > things need to be ironed out still (hopefully there will be an > announcement about that in the near future). > > What I wanted to mention is that according to the new process, there > will be a final release

[openstack-dev] [Neutron] [DVR] easyOVS -- Smart tool to use/debug Neutron/DVR

Hi , all When using neutron (especially with DVR), I find it difficult to debug problems with lots of ovs rules, complicated iptables rules, network namespaces, routing tables, ... So I create easyOVS

Re: [openstack-dev] [Blazar] Anyone interested?

Hi Ildikó, The problem of blazar project was that active contributors moved to different OpenStack projects or leave the community. I want to be in the 'ressurection' process. Also, some other guys might be interested. I remember that I saw some email in dev-list. Nikolay Starodubtsev Software

[openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

We're at a 18hr backup in the gate, which is really unusual given the amount of decoupling. Even under our current load that means we're seeing huge failure rates causing resets. It appears one of the major culprits is the python34 tests in neutron, which were over a 40% failure rate recently - ht

Re: [openstack-dev] info in paste will be removed?

On 2015-08-28 07:06:03 + (+), Osanai, Hisashi wrote: > I would like to know whether info in http://paste.openstack.org > will be removed or not. If it will be removed, I also would like > to know a condition. We (the project infrastructure root sysadmins) don't expire/purge the content on

Re: [openstack-dev] [Blazar] Anyone interested?

Hello, The NSF-funded Chameleon project (https://www.chameleoncloud.org) uses Blazar to provide advance reservations of resources for running cloud computing experiments. We would be interested in contributing as well. Pierre Riteau On 28 Aug 2015, at 07:56, Ildikó Váncsa wrote: > Hi All, >

[openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

Has anyone written anything up about expectations for how "Big Tent" or "Neutron Stadium" projects are expected to be installed/distributed/packaged? In particular, I'm wondering how we're supposed to handle changes to Neutron components. For the networking-sfc project we need to make additio

Re: [openstack-dev] [oslo] About "logging-flexibility"

Hi, Ihar and Dims Thank you for your reply. I uploaded new a patch-set which is a single patch for oslo.log I'd like you to do a code review. https://review.openstack.org/#/c/218139/ After this email, I'd like to add you to reviewer lists. Thank you for your cooperation. Best Regards, Daisuk

Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability zones

Except your failure domain includes the cinder volume service, independent of the resiliency of you backend, so if they're all on one node then you don't really have availability zones. I have historically strongly espoused the same view as Ben, though there are lots of people who want fake availa

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

One of the patches that fixes one of the functional failures that has been hitting is here: https://review.openstack.org/#/c/217927/ However, it failed in the DVR job on the 'test_router_rescheduling' test.[1] This failure is because the logic to skip when DVR is enabled is based on a check that w

Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability zones

Our use case for fake AZs (and why I pushed https://review.openstack.org/#/c/217857/ to enable that sort of behavior) is what Michal outlined, namely that we use Ceph and do not need or want Cinder to add itself to the mix when we're dealing with our failure domains. We already handle that via

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 08/28/2015 08:34 AM, Kevin Benton wrote: > One of the patches that fixes one of the functional failures that has > been hitting is here: https://review.openstack.org/#/c/217927/ > > However, it failed in the DVR job on the 'test_router_rescheduling' > test.[1] This failure is because the logic

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

Why would that only impact py34 and not py27? Aren't the py27 run with testtools? On Fri, Aug 28, 2015 at 5:41 AM, Sean Dague wrote: > On 08/28/2015 08:34 AM, Kevin Benton wrote: > > One of the patches that fixes one of the functional failures that has > > been hitting is here: https://review.o

Re: [openstack-dev] [oslo] About "logging-flexibility"

> On 28 Aug 2015, at 14:16, Fujita, Daisuke > wrote: > > Hi, Ihar and Dims > > Thank you for your reply. > > I uploaded new a patch-set which is a single patch for oslo.log > I'd like you to do a code review. > https://review.openstack.org/#/c/218139/ > > After this email, I'd like to add you

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

> On 28 Aug 2015, at 14:08, Paul Carver wrote: > > Has anyone written anything up about expectations for how "Big Tent" or > "Neutron Stadium" projects are expected to be installed/distributed/packaged? > Seems like your questions below are more about extendability than e.g. packaging. > In

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 28/08/15 13:39, Kevin Benton wrote: > For the py34 failures, they seem to have started around the same time > as a change was merged that adjusted the way they were ran so I > proposed a revert for that patch > here: https://review.openstack.org/218244 > > Which leads on to https://review.opens

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka wrote: > > On 28 Aug 2015, at 14:08, Paul Carver wrote: > > > > Has anyone written anything up about expectations for how "Big Tent" or > "Neutron Stadium" projects are expected to be > installed/distributed/packaged? > > > > Seems like your quest

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On Fri, Aug 28, 2015 at 9:12 AM, Neil Jerram wrote: > On 28/08/15 13:39, Kevin Benton wrote: > > For the py34 failures, they seem to have started around the same time > > as a change was merged that adjusted the way they were ran so I > > proposed a revert for that patch > > here: https://review.

Re: [openstack-dev] [cinder] [nova] Cinder and Nova availability zones

> From: Duncan Thomas [mailto:[email protected]] > Sent: Friday, August 28, 2015 2:31 PM > > Except your failure domain includes the cinder volume service, independent > of the resiliency of you backend, so if they're all on one node then you don't > really have availability zones. > > I ha

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

I don't know if this is really a big problem. IMO, even with microversions you shouldn't be implementing things that aren't backwards compatible within the major version. I thought the benefit of microversions is to know if a given feature exists within the major version you are using. I would cons

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 08/28/2015 09:22 AM, Assaf Muller wrote: > > > On Fri, Aug 28, 2015 at 9:12 AM, Neil Jerram > wrote: > > On 28/08/15 13:39, Kevin Benton wrote: > > For the py34 failures, they seem to have started around the same time > > as a change was merged

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 08/28/2015 08:50 AM, Kevin Benton wrote: > Why would that only impact py34 and not py27? Aren't the py27 run with > testtools? py34 is only running some subset of tests, so there are a lot of ways this can go weird. It may be that the db tests that are failing assume some other tests which hav

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

On 08/28/2015 09:32 AM, Alex Meade wrote: > I don't know if this is really a big problem. IMO, even with > microversions you shouldn't be implementing things that aren't backwards > compatible within the major version. I thought the benefit of > microversions is to know if a given feature exists wi

[openstack-dev] [Heat] Use block_device_mapping_v2 for swap?

I am working with the OS::Nova::Server resource and looking at the tests [1], it should be possible to just define 'swap_size' and get a swap space created on the instance: NovaCompute: type: OS::Nova::Server properties: image: {get_param: Image} ... block_devic

Re: [openstack-dev] [Glance] upcoming glanceclient release

I've compiled a list of backwards incompatabilities where the new client will impact (in some cases break) existing scripts: https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability On 27/08/15 15:32 -0400, Nikhil Komawar wrote: As a part of our continued effort to make the v2 prim

[openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in controller code that is inscrutable. The problem with the spec is that it doesn't know wh

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

Hi, > If you just want to shoot the breeze please respond here. If you > have specific comments on the spec please response there. > I have been thinking about doing it for Ironic as well so I'm looking for options. IMHO after using WSME I would think that one of the most important criteria we sh

Re: [openstack-dev] [Glance] upcoming glanceclient release

On 28/08/15 15:05 +0100, [email protected] wrote: I've compiled a list of backwards incompatabilities where the new client will impact (in some cases break) existing scripts: https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability Awesome! On 27/08/15 15:32 -0400, Nikhil Ko

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 04:36 PM, Lucas Alvares Gomes wrote: Hi, If you just want to shoot the breeze please respond here. If you have specific comments on the spec please response there. I have been thinking about doing it for Ironic as well so I'm looking for options. IMHO after using WSME I would t

Re: [openstack-dev] [nova] contextlib.nested and Python3 failing

On Wed, Aug 19, 2015 at 6:51 PM, Sylvain Bauza wrote: > Hi, > > I was writing some tests so I added a contextlib.nested to a checked > TestCase [1]. Unfortunately, contextlib.nested is no longer available in > Python3 and there is no clear solution on how to provide a compatible > import for both

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 10:36 AM, Lucas Alvares Gomes wrote: > Hi, > >> If you just want to shoot the breeze please respond here. If you >> have specific comments on the spec please response there. >> > > I have been thinking about doing it for Ironic as well so I'm looking > for options. IMHO after usin

Re: [openstack-dev] [Glance] upcoming glanceclient release

I've compiled a list of backwards incompatabilities where the new client will impact (in some cases break) existing scripts: https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability Awesome! To be honest there's a little more red there than I'd like. Of the 72 commands I tried,

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

To recap, we had three issues impacting the gate queue: 1) The neutron functional job has had a high failure rate for a while now. Since it's impacting the gate, I've removed it from the gate queue but kept it in the Neutron check queue: https://review.openstack.org/#/c/218302/ If you'd like to h

Re: [openstack-dev] [cinder][third-party] StorPool Cinder CI

On Fri, Aug 28, 2015 at 1:03 AM, Peter Penchev wrote: > On Fri, Aug 28, 2015 at 12:22 AM, Asselin, Ramy wrote: >> Hi Peter, >> >> Your log files require downloads. Please fix it such that they can be viewed >> directly [1] > > Hi, and thanks for the fast reply! Yes, I'll try to change the > web

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On Fri, Aug 28 2015, Chris Dent wrote: > This morning I kicked off a quick spec for replacing WSME in > Ceilometer with ... something: > > https://review.openstack.org/#/c/218155/ > > This is because not only is WSME not that great, it also results in > controller code that is inscrutable. > >

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

On Aug 28, 2015 6:49 AM, "Sean Dague" wrote: > > On 08/28/2015 09:32 AM, Alex Meade wrote: > > I don't know if this is really a big problem. IMO, even with > > microversions you shouldn't be implementing things that aren't backwards > > compatible within the major version. I thought the benefit of

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 08/28/2015 11:20 AM, Assaf Muller wrote: > To recap, we had three issues impacting the gate queue: > > 1) The neutron functional job has had a high failure rate for a while > now. Since it's impacting the gate, > I've removed it from the gate queue but kept it in the Neutron check queue: > http

Re: [openstack-dev] [Glance] upcoming glanceclient release

On Fri, Aug 28, 2015 at 5:12 PM, wrote: > > >>> I've compiled a list of backwards incompatabilities where the new client >>> will impact (in some cases break) existing scripts: >>> >>> https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability >>> >> > Awesome! >> > > To be honest there's

[openstack-dev] [nova] Nova migration policy

In an effort to clarify expectations around good practices in writing schema and data migrations in nova with respect to live upgrades, I’ve added some extra bits to the live upgrade devref. Please check it out and add your thoughts: https://review.openstack.org/#/c/218362/

[openstack-dev] [nova][bugs] more specific tags?

This is a proposal to enhance the list of offical tags for our bugs in Launchpad. During the tagging process in the last weeks it seems to me that some of the tags are too coarse-grained. Would you see a benefit in enhancing the official list to more fine-grained tags? Additionally I would like to

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

On Thu, 27 Aug 2015 15:37:24 -0400 gord at live.ca (gord chung) wrote: > polling agent --- topic queue ---> notification agent --- topic queue > ---> collector (direct connection to db) > or > OpenStack service --- topic queue ---> notification agent --- topic > queue ---> collector (direct conn

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 07:22 AM, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in controller code that is inscrutable. The prob

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

I enjoy using validictory for using Jsonschema with Python https://pypi.python.org/pypi/validictory. Sent from my iPhone > On Aug 28, 2015, at 11:29 AM, Jay Pipes wrote: > >> On 08/28/2015 07:22 AM, Chris Dent wrote: >> >> This morning I kicked off a quick spec for replacing WSME in >> Ceilom

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On Fri, Aug 28 2015, Jay Pipes wrote: > voluptuous may be more Pythonic, as Julien mentioned, but the problem is you > can't expose the validation schema to the end user via any standard document > format (like JSONSchema). Using the jsonschema library along with standard > JSONSchema documents al

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

> there was a little skeptism because it was originally sold as magic, > but reading the slides from Vancouver[1], it is not magic. I think I specifically said "they're not magic" in my slides. Not sure who sold you them as magic, but you should leave them a less-than-five-stars review. > Ceilome

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

Markus Zoeller/Germany/IBM@IBMDE wrote on 08/19/2015 02:15:55 PM: > From: Markus Zoeller/Germany/IBM@IBMDE > To: "OpenStack Development Mailing List \(not for usage questions\)" > > Date: 08/19/2015 02:31 PM > Subject: Re: [openstack-dev] [openstack][nova] Streamlining of config > options in no

Re: [openstack-dev] [fuel] Branching strategy vs feature freeze

On Fri, Aug 28, 2015 at 1:13 AM Igor Marnat wrote: > Dmitry, > I don't have yet enough context to discuss Fuel 9.0 release but I have > a question about 8.0. > > You mentioned that "the start of Fuel 8.0 release cycle inevitably > remains coupled with MOS". Does it mean that we still consider > d

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

On 28/08/15 12:18 PM, Roman Dobosz wrote: So imagine we have new versions of the schema for the events, alarms or samples in ceilometer introduced in Mitaka release while you have all your ceilo services on Liberty release. To upgrade ceilometer you'll have to stop all services to avoid data co

Re: [openstack-dev] [openstack][nova] Streamlining of config options in nova

Markus, C) +1 to file a spec early, so we can discuss in Tokyo if needed. Thanks, dims On Fri, Aug 28, 2015 at 11:16 AM, Markus Zoeller wrote: > Markus Zoeller/Germany/IBM@IBMDE wrote on 08/19/2015 02:15:55 PM: > > > From: Markus Zoeller/Germany/IBM@IBMDE > > To: "OpenStack Development Mailing

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

On 28/08/15 12:49 PM, Dan Smith wrote: there was a little skeptism because it was originally sold as magic, but reading the slides from Vancouver[1], it is not magic. I think I specifically said "they're not magic" in my slides. Not sure who sold you them as magic, but you should leave them a

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

On 8/28/15, 10:07 AM, "gord chung" wrote: > > >On 28/08/15 12:18 PM, Roman Dobosz wrote: >> So imagine we have new versions of the schema for the events, alarms or >> samples in ceilometer introduced in Mitaka release while you have all >> your ceilo services on Liberty release. To upgrade ceil

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On 28 August 2015 at 16:57, Sean Dague wrote: > On 08/28/2015 11:20 AM, Assaf Muller wrote: > > To recap, we had three issues impacting the gate queue: > > > > 1) The neutron functional job has had a high failure rate for a while > > now. Since it's impacting the gate, > > I've removed it from th

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 07:36 AM, Lucas Alvares Gomes wrote: Hi, If you just want to shoot the breeze please respond here. If you have specific comments on the spec please response there. I have been thinking about doing it for Ironic as well so I'm looking for options. IMHO after using WSME I would t

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

> we store everything as primitives: floats, time, integer, etc... since > we need to query on attributes. it seems like versionedobjects might not > be useful to our db configuration currently. I don't think the former determines the latter -- we have lots of things stored as rows of column primi

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 08:32 AM, Julien Danjou wrote: On Fri, Aug 28 2015, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in con

Re: [openstack-dev] [Fuel] How much do we rely on dnsmasq?

On Thu, Aug 27, 2015 at 08:27:24PM EDT, Andrey Danin wrote: > Hi, Sean, > > Dnsmasq is managed by Cobbler. Cobbler may also manage isc-dhcpd + BIND > [0]. Great - thanks for the link. > So, switching from dnsmasq requires 2 more services been installed. I > think it's not a big deal to a update

Re: [openstack-dev] [nova][manila] "latest" microversion considered dangerous

On 8/28/2015 10:35 AM, Joe Gordon wrote: On Aug 28, 2015 6:49 AM, "Sean Dague" mailto:[email protected]>> wrote: > > On 08/28/2015 09:32 AM, Alex Meade wrote: > > I don't know if this is really a big problem. IMO, even with > > microversions you shouldn't be implementing things that aren't ba

Re: [openstack-dev] --detailed-description for OpenStack items

On 8/28/2015 2:38 AM, Tim Bell wrote: -Original Message- From: Matt Riedemann [mailto:[email protected]] Sent: 28 August 2015 02:29 To: [email protected] Subject: Re: [openstack-dev] --detailed-description for OpenStack items On 8/27/2015 12:23 PM, Tim Bel

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 08:32 AM, Julien Danjou wrote: On Fri, Aug 28 2015, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it also results in con

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

Monty Taylor wrote: On 08/28/2015 08:32 AM, Julien Danjou wrote: On Fri, Aug 28 2015, Chris Dent wrote: This morning I kicked off a quick spec for replacing WSME in Ceilometer with ... something: https://review.openstack.org/#/c/218155/ This is because not only is WSME not that great, it als

Re: [openstack-dev] [Fuel] How much do we rely on dnsmasq?

My biggest concern is about 4to6 translations. I would prefer to avoid them as longer as it possible. >From my point of view pure ipv6 is easier to implement than dual stack. I see it like when you install Fuel node you decide once and forever what IP version you are go with. We will have two impl

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

i should start by saying i re-read my subject line and it arguably comes off aggressive -- i should probably have dropped 'explain' :) On 28/08/15 01:47 PM, Alec Hothan (ahothan) wrote: On 8/28/15, 10:07 AM, "gord chung" wrote: On 28/08/15 12:18 PM, Roman Dobosz wrote: So imagine we have

[openstack-dev] [puppet] [tempest] CI - integration job status

So this week we managed to iterate to have more components part of Puppet OpenStack Integration CI. Everything is work in progress but let me share the status: * one single Puppet run of the scenario001.pp is enough to deploy OpenStack (MySQL, RabbitMQ, Keystone WSGI, Nova, Glance, Neutron (ML2-OV

[openstack-dev] [Gnocchi] Added Ilya Tyaptin as core reviewer

Hi fellows, Ilya did a few good contributions to Gnocchi, especially around the InfluxDB driver, so I'm glad to add him to the list of core reviewers. Welcome aboard. Cheers, -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature ___

Re: [openstack-dev] [neutron] 40% failure on neutron python3.4 tests in the gate

On Fri, Aug 28, 2015 at 1:50 PM, Salvatore Orlando wrote: > > > On 28 August 2015 at 16:57, Sean Dague wrote: > >> On 08/28/2015 11:20 AM, Assaf Muller wrote: >> > To recap, we had three issues impacting the gate queue: >> > >> > 1) The neutron functional job has had a high failure rate for a wh

Re: [openstack-dev] [Gnocchi] Added Ilya Tyaptin as core reviewer

On 28/08/15 02:48 PM, Julien Danjou wrote: Hi fellows, Ilya did a few good contributions to Gnocchi, especially around the InfluxDB driver, so I'm glad to add him to the list of core reviewers. Welcome aboard. Cheers, _

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 2015-08-28 11:27:57 -0700 (-0700), Joshua Harlow wrote: > Out of curiosity how are u using voluptuous (and/or getting it installed?), > when I tried to propose that to the global requirements requirement > list/repo I got shot-down (since json-schema does similar things); Zuul uses voluptuous t

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On 08/28/2015 10:36 AM, Lucas Alvares Gomes wrote: So at the present moment the [micro]framework that comes to my mind - without any testing or prototype of any sort - is Flask. just wanted to add on here, sahara is using flask. mike __

Re: [openstack-dev] [oslo][versionedobjects][ceilometer] explain the benefits of ceilometer+versionedobjects

On 8/28/15, 11:39 AM, "gord chung" wrote: >i should start by saying i re-read my subject line and it arguably comes >off aggressive -- i should probably have dropped 'explain' :) > >On 28/08/15 01:47 PM, Alec Hothan (ahothan) wrote: >> >> On 8/28/15, 10:07 AM, "gord chung" wrote: >> >>> >>

[openstack-dev] [neutron] Core Reviewer participation in the weekly meeting

I'm sending out this email to encourage Neutron core reviewers to attend and participate in the weekly Neutron team meeting [1]. Attendance from core reviewers has been very low for a while now, and this is the one time each week (or bi-weekly if you attend only one of the rotating meeting) I have

[openstack-dev] [neutron] Pecan and Liberty-3

Folks: Kevin wants to merge the pecan stuff, and I agree with him. I'm on vacation next week during Liberty-3, so Armando, Carl and Doug are running the show while I'm out. I would guess that if Kevin thinks it's ok to merge it in before Liberty-3, I'd go with his opinion and let it happen. If not

Re: [openstack-dev] [magnum] versioned objects changes

Ryan, Thanks for sharing your inputs. By looking through your response, I couldn't find the reasoning about why a young project is the perfect time to enforce a strict object version rule. I think a young project often starts with a static (or non-frequently changing) version until a point in t

[openstack-dev] [tc][app-catalog] Application for inclusion in big tent

Hello! We put together our details and submitted a review for adding the Community App Catalog project to the OpenStack governance projects list [1]. We are looking forward to continuing to grow the catalog in cooporation with the other projects, and building this showcase of all the things that c

Re: [openstack-dev] [magnum] versioned objects changes

> If you want my inexperienced opinion, a young project is the perfect > time to start this. ^--- This ---^ > I understand that something like [2] will cause a test to fail when you > make a major change to a versioned object. But you *want* that. It helps > reviewers more easily catch co

Re: [openstack-dev] info in paste will be removed?

On Friday, August 28, 2015 8:49 PM, Jeremy Stanley wrote: > We (the project infrastructure root sysadmins) don't expire/purge > the content on paste.openstack.org, though have deleted individual > pastes on request if someone reports material which is abusive or > potentially illegal in many juri

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

It seems like Flask has a reasonable amount of support and there is a good ecosystem around it but that aside (as Jay said)... I definitely support exposing the schema to the end user; making it easier for the end user to validate input / model outputs for their integration with OpenStack services

Re: [openstack-dev] [neutron] Pecan and Liberty-3

I'll leave to Kevin's more informed judgment to comment on whether it is appropriate to merge: [1] is a list of patches still under review on the feature branch. Some of them fix issues (like executing API actions), or implement TODOs This is the current list of TODOs: salvatore@ubuntu:/opt/stack

Re: [openstack-dev] [neutron] Pecan and Liberty-3

This weekend or early next week I will be pushing a couple of more patches to deal with some of the big TODOs (e.g. bulk). Then we can rename it and see if we can review the merge. I don't intend to have it fully replace our built-in WSGI solution in Liberty. It's too late in the cycle to make tha

Re: [openstack-dev] [api] [wsme] [ceilometer] Replacing WSME with _____ ?

On Aug 28, 2015, at 6:10 PM, Morgan Fainberg wrote: > It seems like Flask has a reasonable amount of support and there is a good > ecosystem around it but that aside (as Jay said)... I definitely support > exposing the schema to the end user; making it easier for the end user to > validate inp

[openstack-dev] Tracing a request (NOVA)

Hi, I'm trying to trace a request made for an instance and looking at the flow in the code. I'm just trying to understand better how the request goes from the dashboard to the nova-api , to the other internal components of nova and to the scheduler and back with a suitable host and launching of th

Re: [openstack-dev] [magnum] versioned objects changes

Hongbin, We are hearing the best advice available from the folks who started the library, evangelized it across nova, ironic, heat, neutron etc. If we can spend so much time and energy (*FOUR* -1's on a review which just changes some commented lines - https://review.openstack.org/#/c/211057/) the

[openstack-dev] [heat] Deployment of Lock / Unlock Operation like MUTEX

Hello, Here is a situation which I faced, that can be reproduced. I did "heat resource-signal" multiple times simultaneously to scale instance. As a result 3 resources were made in the scaling group having max_size=2. "stack-list -n" showed me 3 stacks in one parent. Heat itself seems not to ac

  1   2   >