Re: [openstack-dev] [Horizon] Rethinking the launch-instance wizard model

Richard, I have been thinking for some time that each step controller should be able to define the data it needs as well as manipulating it. Perhaps in the morning before you get up in Australia I could take a pass at converting that for access & security. I’ll talk it over with Sean, since t

[openstack-dev] [kolla] about the image size

Hi, stackers I try to use the Kolla Images and pull them down from docker hub. I found the size of the image is bigger than what I thought(for example, the images of docker conductor service is about 1.4GB). Is it possible to get a more smaller images. Do we have the plan to minimize the images.

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

- Original Message - > From: "Jan Provazník" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Monday, 9 March, 2015 8:35:29 PM > Subject: [openstack-dev] [TripleO][Tuskar] Common library for shared code > > Hi, > it would make sense to have a library for th

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

I have done the first version, follow this discussion I separated them into two patches: 1. The discussion about eliminated extension: https://review.openstack.org/162912 2. The discussion about modularity: https://review.openstack.org/162913 After begin the writefound I loss some confidence

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

2015-03-10 3:37 GMT+08:00 Jay Pipes : > On 03/08/2015 08:10 AM, Alex Xu wrote: > >> Thanks for Jay point this out! If we have agreement on this and document >> it, that will be great for guiding developer how to add new API. >> >> I know we didn't want extension for API. But I think we still >> ne

Re: [openstack-dev] [Fuel] Logstash and grok patterns

Hi, Here are some suggestions from my experience: 1. Input patterns could be simplified by * matches, e.g.: file { path => [ "/var/log/remote/*.domain.tld/neutron*" ] exclude => "*.gz" } 2. Logs could be parsed by the following pattern: grok { patterns_dir => "patterns" match

[openstack-dev] [vmware] Alternate meeting times

Hi, As mentioned a few weeks ago we would like to have alternate meeting times for the Vmware driver(s) meeting. So for all interested lets meet tomorrow at 10:00 UTC on #openstack-meeting-4. Thanks Gary __ OpenStack Develo

Re: [openstack-dev] [nova] Unshelve Instance Performance Optimization Questions

Hi Devs, As another alternative we can use start/stop API’s instead of shelve/unshelve the instance. API’s cpu/memory released Disk released Fast respawning Notes start/stop No No Yes shelve/unshelve Yes Yes (Not released if shelved_offload_time = -1) No Instance does not respawn

Re: [openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

On 03/06/2015 03:19 PM, Attila Fazekas wrote: > Looks like we need some kind of _per compute node_ mutex in the critical > section, > multiple scheduler MAY be able to schedule to two compute node at same time, > but not for scheduling to the same compute node. > > If we don't want to introduce a

Re: [openstack-dev] [murano] how can deploy environment with useEnvironmentNerwork=false

Hi Choe! Why do you want to set this option to false? In that way new instance will not be connected to the environment network. Do you have any issues with the deployment? If you still want to try the deployment without handling networks by default, you need to set default value of specified p

Re: [openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

- Original Message - > From: "Jay Pipes" > To: [email protected] > Sent: Wednesday, March 4, 2015 9:22:43 PM > Subject: Re: [openstack-dev] [nova] blueprint about multiple workers > supported in nova-scheduler > > On 03/04/2015 01:51 AM, Attila Fazekas wrote: > > Hi,

[openstack-dev] [murano] Application Usage Information Tracking

Hi everyone, I would like to know if the application usage information is tracked by the murano-agent? If not, how is it done? Is ceilometer used at all, anywhere? Regards Darshan __ OpenStack Development Mailing List (not fo

Re: [openstack-dev] [Fuel] Recent issues with our review workflow

On 03/09/2015 06:21 PM, Ryan Moe wrote: > Hi All, > > I've noticed a few times recently where reviews have been abandoned by > people who were not the original authors. These reviews were only days > old and there was no prior notice or discussion. This is both rude and > discouraging to contribut

Re: [openstack-dev] [Fuel] Recent issues with our review workflow

> On 09 Mar 2015, at 18:21, Ryan Moe wrote: > > Hi All, > > I've noticed a few times recently where reviews have been abandoned by people > who were not the original authors. These reviews were only days old and there > was no prior notice or discussion. This is both rude and discouraging to

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On Mon, 09 Mar 2015 16:14:21 -0400 Sean Dague wrote: > On 03/09/2015 03:37 PM, Jay Pipes wrote: > > On 03/08/2015 08:10 AM, Alex Xu wrote: > >> Thanks for Jay point this out! If we have agreement on this and > >> document it, that will be great for guiding developer how to add > >> new API. > >>

Re: [openstack-dev] [api][neutron] Best API for generating subnets from ool

Thanks for bringing up this use case Miguel - these are the use cases we need to make informed decisions. Some answers inline. Salvatore On 10 March 2015 at 07:53, Miguel Ángel Ajo wrote: > Thanks to everybody working on this, > > Answers inline: > > On Tuesday, 10 de March de 2015 at 0:34, Tid

Re: [openstack-dev] [Ironic] proposing rameshg87 to ironic-core

Though my vote does not count, definitely a +1 On Tue, Mar 10, 2015 at 6:37 AM, Ruby Loo wrote: > +1 for sure! > > On 9 March 2015 at 18:03, Devananda van der Veen > wrote: > >> Hi all, >> >> I'd like to propose adding Ramakrishnan (rameshg87) to ironic-core. >> >> He's been consistently provid

Re: [openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

- Original Message - > From: "Nikola Đipanov" > To: [email protected] > Sent: Tuesday, March 10, 2015 10:53:01 AM > Subject: Re: [openstack-dev] [nova] blueprint about multiple workers > supported in nova-scheduler > > On 03/06/2015 03:19 PM, Attila Fazekas wrote: > >

Re: [openstack-dev] [oslo][messaging][zmq] Discussion on zmq driver design issues

Hi Li Ma, Thank you very much for your reply On 06.03.15 05:01, Li Ma wrote: Hi all, actually I'm writing the same mail topic for zeromq driver, but I haven't done it yet. Thank you for proposing this topic, ozamiatin. 1. ZeroMQ functionality Actually I proposed a session topic in the coming

Re: [openstack-dev] [murano] Application Usage Information Tracking

Hi Darshan, Unfortunately application usage is not tracked in Murano in any way. We only have special logging message [1] that can help to organize tracking of usage using some sort tools for log analysis (e.g. Logstash). [1] https://github.com/stackforge/murano/blob/73f8368024acc2f79ef4494b1fbf

Re: [openstack-dev] [oslo][messaging][zmq] Discussion on zmq driver design issues

Hi, Eric Thanks a lot for your comments. On 06.03.15 06:21, Eric Windisch wrote: On Wed, Mar 4, 2015 at 12:10 PM, ozamiatin > wrote: Hi, By this e-mail I'd like to start a discussion about current zmq driver internal design problems I've found out.

Re: [openstack-dev] [nova] blueprint about multiple workers supported in nova-scheduler

- Original Message - > From: "Attila Fazekas" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, March 10, 2015 12:48:00 PM > Subject: Re: [openstack-dev] [nova] blueprint about multiple workers > supported in nova-scheduler > > > > > >

Re: [openstack-dev] [nova][api] Microversions. And why do we need API extensions for new API functionality?

On 03/09/2015 06:04 PM, melanie witt wrote: On Mar 9, 2015, at 13:14, Sean Dague wrote: So possibly another way to think about this is our prior signaling of what was supported by Nova was signaled by the extension list. Our code was refactored into a way that supported optional loading by t

Re: [openstack-dev] [murano] how can deploy environment with useEnvironmentNerwork=false

Hi Cheng-Dae, We are working on improving supported networking schemes, please take a look on following commits: * https://review.openstack.org/152643 - Adds ability to join instances to existing Neutron networks * https://review.openstack.org/152747 - Configurable environment's default network co

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

Hi Anne, How about driver documentation that is in the old format? Will it be removed in Kilo? The wiki says: "Bring all driver sections that are currently just ‘bare bones’ up to the standard mentioned." Will this be performed by core team? Thanks, Erlon On Fri, Mar 6, 2015 at 4:58 PM, Anne Gen

Re: [openstack-dev] [Magnum][Heat] Expression of Bay Status

On 09/03/15 23:47, Angus Salkeld wrote: On Tue, Mar 10, 2015 at 8:53 AM, Adrian Otto mailto:[email protected]>> wrote: Magnum Team, In the following review, we have the start of a discussion about how to tackle bay status: https://review.openstack.org/159546 I thin

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

On Tue, Mar 10, 2015 at 8:28 AM, Erlon Cruz wrote: > Hi Anne, > > How about driver documentation that is in the old format? Will it be > removed in Kilo? > Hi Erlon, The spec doesn't have a specific person assigned for removal, and the only drivers the docs team "signed up for" through the blue

Re: [openstack-dev] [cinder]difference between spec merged and BP approval

Hi David, On Sat, 2015-03-07 at 02:22 +, Chen, Wei D wrote: > I thought the feature should be approved as long as the SPEC[1] is > merged, but it seems I am wrong from the beginning[2], both of > them (SPEC merged and BP approval[4][5]) is necessary and mandatory > for getting some effective r

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Clint Byrum wrote: > > Please try to refrain from using false equivalence. ACID stands for > Atomicity, Consistency, Isolation, Durability. Nowhere in there does it > stand for "referential integrity”. This point is admittedly controversial as I’ve had this debate before, but it is common th

Re: [openstack-dev] [nova] Deprecation of ComputeFilter

Hi Sylvain, The list of filters does not only determine what conditions are checked, it also specifies the order in which they are checked. If I read the code right this change creates the worst case efficiency for this filter. Normally you would filter first on something that removes as many n

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Adam Young wrote: > On 03/09/2015 01:26 PM, Mike Bayer wrote: >> Im about -1000 on disabling foreign key constraints. > So was I. We didn't do it out of performance. > > Since I am responsible for tipping over this particular cow, let me explain. > > No, is too much. Let me sum up. > > In t

Re: [openstack-dev] [cinder] 3rd Party CI failures ignored, caused driver to break

Agreed, CI systems are not reliable. Most of failures are related to mis-configuration or devstack problems, not driver problems itself. What happen then, is that people just don't care if there's a red FAILURE in the CIs results. A 4) option would be to rate CIs according to their trustfulness (ma

[openstack-dev] [python-novaclient] Better wording for secgroup-*-default-rules? help text

I've just filed a bug on the confusing wording of help text for the secgroup-{add,delete,list}-default-rules? commands: https://bugs.launchpad.net/python-novaclient/+bug/1430354 As I note in the bug, though, I'm not sure the best way to fix this. In an unconstrained world, I'd like to see somethin

Re: [openstack-dev] [Magnum][Heat] Expression of Bay Status

Hi Adrian, On Mon, Mar 9, 2015 at 6:53 PM, Adrian Otto wrote: > Magnum Team, > > In the following review, we have the start of a discussion about how to > tackle bay status: > > https://review.openstack.org/159546 > > I think a key issue here is that we are not subscribing to an event feed > fro

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Mike Bayer wrote: > >> I'm not entirely sure what you've said above actually prevents coders >> from relying on the constraints. Being careful about deleting all of the >> child rows before a parent is good practice. I have seen code like this >> in the past though: >> >> try: >> parent.delet

Re: [openstack-dev] [Openstack-operators] [all][qa][gabbi][rally][tempest] Extend "rally verfiy" to unify work with Gabbi, Tempest and all in-tree functional tests

Hi, I like this idea, we use Rally for OpenStack clouds verification at scale and it is the real issue - how to run all functional tests from each project with the one script. If Rally will do this, I will use Rally to run these tests. Thank you! On Mon, Mar 9, 2015 at 6:04 PM, Chris Dent wrote

[openstack-dev] [neutron][third party] best packaging practices

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, RDO project started to look into packaging some of vendor libraries that were split from neutron tree during Kilo for Delorean, and found some issues with some of pypi packages that were released in public. We feel that communicating each ven

[openstack-dev] [neutron][third party] Major third party CI breakage expected for out-of-tree plugins

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, team is going to merge in a patch to migrate to oslo.log [1] in the very near future. This patch is expected to break all third party CI for all vendor libraries that were split from the main repo in Kilo and that rely on neutron.openstack.com

[openstack-dev] Avoiding regression in project governance

The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. Another critical part was replacing the integrate

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 10:29 AM, Russell Bryant wrote: > The TC is in the middle of implementing a fairly significant change in > project governance. You can find an overview from Thierry on the > OpenStack blog [1]. > > Part of the change is to recognize more projects as being part of the > Op

Re: [openstack-dev] [log] Log working group -- Alternate moderator needed for today

You mean for tomorrow? No worries, I can kick off the meeting and run through agenda if we have something to address. Take best out of the ops meetup! - Erno From: Rochelle Grober [mailto:[email protected]] Sent: Tuesday, March 10, 2015 4:04 PM To: OpenStack Development Maili

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: > The TC is in the middle of implementing a fairly significant change in > project governance. You can find an overview from Thierry on the > OpenStack blog [1]. > > Part of the change is to recognize more projects as being part of the >

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015, at 12:46 PM, Doug Hellmann wrote: > > > On Tue, Mar 10, 2015, at 12:29 PM, Russell Bryant wrote: > > The TC is in the middle of implementing a fairly significant change in > > project governance. You can find an overview from Thierry on the > > OpenStack blog [1]. > > >

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

Honestly, I'm a little frustrated that this is coming up now when we tried very hard to discuss this during the spec review and we thought we got to a resolution. It seems a little late to go back to the drawing board. On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando wrote: > The problem with t

[openstack-dev] [oslo] must-fix bugs for final kilo releases

I have started an etherpad to track bugs we consider critical for final releases of incubator modules and library code for Kilo. I added the 2 items discussed in yesterday's meeting, but please add other items to the list as needed so we can track them. Thanks, Doug https://etherpad.openstack.org

Re: [openstack-dev] [TripleO][Tuskar] Common library for shared code

On Mon, Mar 9, 2015 at 4:35 PM, Jan Provazník wrote: > Hi, > it would make sense to have a library for the code shared by Tuskar UI and > CLI (I mean TripleO CLI - whatever it will be, not tuskarclient which is > just a thing wrapper for Tuskar API). There are various actions which > consist from

Re: [openstack-dev] [heat] Unknown resource OS::Heat::ScaledResource

On Tue, Mar 10, 2015 at 04:26:28PM +, Manickam, Kanagaraj wrote: >Hi, > > > >I observed in one of the patch mentioned below, OS::Heat::ScaledResource >is reported as unknown, could anyone help here to resolve the issue. >Thanks. > > > > > http://logs.openstack.

Re: [openstack-dev] [heat] Unknown resource OS::Heat::ScaledResource

On 10/03/15 12:26, Manickam, Kanagaraj wrote: Hi, I observed in one of the patch mentioned below, OS::Heat::ScaledResource is reported as unknown, could anyone help here to resolve the issue. Thanks. http://logs.openstack.org/76/157376/8/check/check-heat-dsvm-functional-mysql/c9a1be3/logs/scree

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

Excerpts from Mike Bayer's message of 2015-03-10 08:35:23 -0700: > > Mike Bayer wrote: > > > > >> I'm not entirely sure what you've said above actually prevents coders > >> from relying on the constraints. Being careful about deleting all of the > >> child rows before a parent is good practice.

[openstack-dev] [neutron][lbaas] v2 vendor drivers

Hi all, LBaaS v2 is going out in Kilo, and we have quite a few vendor drivers ready to merge, but most are waiting for the tempest tests/job to be done before they can satisfy their third-party CI requirements. Because that job is likely to be done so close to FF for Kilo, I am proposing that

Re: [openstack-dev] [Keystone]ON DELETE RESTRICT VS ON DELETE CASCADE

On 03/10/2015 10:23 AM, Mike Bayer wrote: if*that’s* what you mean, that’s known as a “polymorphic foreign key”, and it is not actually a foreign key at all, it is a terrible antipattern started by the PHP/Rails community and carried forth by projects like Django. A) Heh. it is much, much older

[openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Neutron currently does not enforce the uniqueness, or non-overlap, of subnet cidrs within the address scope for a single tenant. For example, if a tenant chooses to use 10.0.0.0/24 on more than one subnet, he or she is free to do so. Problems will arise when trying to connect a router between the

Re: [openstack-dev] [Congress]How to add tempest tests for testing murano drive

Hi Aaron, I just want to confirm how CI is running the congress tempest tests in its environment as I am about to check in a tempest test for testing murano deployment. If I check in the test script to congress/contrib/tempest/tempest/scenario/congress_datasources, the CI will take care of ru

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Em 10.03.2015 14:24, Carl Baldwin escreveu: Neutron currently does not enforce the uniqueness, or non-overlap, of subnet cidrs within the address scope for a single tenant. For example, if a tenant chooses to use 10.0.0.0/24 on more than one subnet, he or she is free to do so. Problems will ari

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Em 10.03.2015 14:34, Gabriel Bezerra escreveu: Em 10.03.2015 14:24, Carl Baldwin escreveu: Neutron currently does not enforce the uniqueness, or non-overlap, of subnet cidrs within the address scope for a single tenant. For example, if a tenant chooses to use 10.0.0.0/24 on more than one subnet,

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On Tue, Mar 10, 2015 at 10:38 PM, Gabriel Bezerra wrote: > Em 10.03.2015 14:34, Gabriel Bezerra escreveu: > > Em 10.03.2015 14:24, Carl Baldwin escreveu: >> Neutron currently does not enforce the uniqueness, or non-overlap, of >> subnet cidrs within the address scope for a single tenant. For >>

[openstack-dev] Second Release of Magnum

We are proud to announce our second release of Magnum [1]. This release [2] includes numerous improvements, including significant test code coverage, multi-tenancy support, scalable bays, and support for CoreOS Nodes, 8 bit character support, and 52 other enhancements, bug fixes, and technical d

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Mon, Mar 9, 2015 at 5:34 PM, Tidwell, Ryan wrote: > With implicit allocations, the thinking is that this is where a subnet is > created in a backward-compatible way with no subnetpool_id and the subnets > API’s continue to work as they always have. Correct. > In the case of a specific subnet

Re: [openstack-dev] [api][neutron] Best API for generating subnets from ool

On Tue, Mar 10, 2015 at 12:53 AM, Miguel Ángel Ajo wrote: > a) What if the subnet pools go into an external network, so, the gateway is > predefined and external, we may want to be able to specify it, we could > assume the convention that we’re going to expect the gateway to be on the > first IP

Re: [openstack-dev] [Manila] FYI : Micro-versioning for Nova API

On 03/09/2015 08:48 PM, Li, Chen wrote: Hello Manila, I noticed there were some discussions about api extensions in the past few weeks. Looks like nova has similar discussions too. “Each extension gets a version”, if my understanding about the api extension discussion purpose is correct.

[openstack-dev] [Glance] [all] glance_store release 0.3.0

The glance_store release management team is pleased to announce: glance_store version 0.3.0 has been released on Tuesday March 10th around 1755 UTC. For more information, please find the details at: https://launchpad.net/glance-store/+milestone/v0.3.0 Please report the issues through l

Re: [openstack-dev] Avoiding regression in project governance

Russell Bryant wrote: > [...] > We now have several new project proposals. However, I propose not > approving any new projects until we have a tagging system that is at > least far enough along to represent the set of criteria that we used to > apply to all OpenStack projects (with exception for o

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

Gabriel Bezerra wrote on 03/10/2015 12:34:30 PM: > > Em 10.03.2015 14:24, Carl Baldwin escreveu: > > Neutron currently does not enforce the uniqueness, or non-overlap, of > > subnet cidrs within the address scope for a single tenant. For > > example, if a tenant chooses to use 10.0.0.0/24 on m

Re: [openstack-dev] [Neutron][IPAM] Uniqueness of subnets within a tenant

On Tue, Mar 10, 2015 at 11:34 AM, Gabriel Bezerra wrote: > Em 10.03.2015 14:24, Carl Baldwin escreveu: > I'd vote for allowing against such restriction, but throwing an error in > case of creating a router between the subnets. > > I can imagine a tenant running multiple instances of an application

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On 10 March 2015 at 16:48, Carl Baldwin wrote: > Honestly, I'm a little frustrated that this is coming up now when we > tried very hard to discuss this during the spec review and we thought > we got to a resolution. It seems a little late to go back to the > drawing board. > I guess that frustr

Re: [openstack-dev] Avoiding regression in project governance

Blocking the acceptance of new projects seems punitive and against the spirit of the big tent. Classification (tagging) can be done at any point, and is hardly fixed in stone. You can refine tags as needed. To put it harshly: it is a failure of both leadership and process to have stripped out t

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 9:29 AM, Russell Bryant wrote: > The TC is in the middle of implementing a fairly significant change in > project governance. You can find an overview from Thierry on the > OpenStack blog [1]. > > Part of the change is to recognize more projects as being part of the > Ope

Re: [openstack-dev] [stacktach] [oslo] stachtach -> kombu -> pika ??

Hey J, Our (old) notification consumer was using carrot, which is dead but worked. Lately though there have been conflicts with carrot and msgpack, so we had to change. Around the same time, we ran into a bug where we were writing to an unnamed exchange (completely valid, but too easy to do und

[openstack-dev] Controlling data sent to client

Hi, I am using open stack swift server. Now say multiple clients are requesting 5GB object from server. The rate at which server can push data into server socket is much more than the rate at which client can read it from proxy server. Is there configuration / setting which we use to control / cap

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 02:00 PM, Thierry Carrez wrote: > Russell Bryant wrote: >> [...] >> We now have several new project proposals. However, I propose not >> approving any new projects until we have a tagging system that is at >> least far enough along to represent the set of criteria that we used to >>

Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando wrote: > I guess that frustration has now become part of the norm for Openstack. > It is not the first time I frustrate people because I ask to reconsider > decisions approved in specifications. I'm okay revisiting decisions. It is just the tim

Re: [openstack-dev] Avoiding regression in project governance

One point of clarification: On 03/10/2015 02:28 PM, Gabriel Hurley wrote: > Even more concerning is the sentiment of "projects we want to > consciously drop" from Russell's original email. This was in reference to criteria defined in: http://governance.openstack.org/reference/incubation-integrat

Re: [openstack-dev] [Murano][Heat][Mistral] Use and adoption of YAQL

I would suggest to do the migration but not to merge it till official yaql 1.0 release which is going to happen soon. As for the docs it is still very hard to write them since yaql 1.0 has got tons on new features and hundreds of functions. Any help is appreciated. But 99% of yaql 1.0 features and

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 02:43 PM, Thierry Carrez wrote: > Joe Gordon wrote: >> On Tue, Mar 10, 2015 at 9:29 AM, Russell Bryant > > wrote: >>> We now have several new project proposals. However, I propose not >>> approving any new projects until we have a tagging system tha

Re: [openstack-dev] Avoiding regression in project governance

Russell Bryant wrote: > One point of clarification: > > On 03/10/2015 02:28 PM, Gabriel Hurley wrote: >> Even more concerning is the sentiment of "projects we want to >> consciously drop" from Russell's original email. > > This was in reference to criteria defined in: > > http://governance.opens

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 12:29 PM, Russell Bryant wrote: The TC is in the middle of implementing a fairly significant change in project governance. You can find an overview from Thierry on the OpenStack blog [1]. Part of the change is to recognize more projects as being part of the OpenStack community. A

Re: [openstack-dev] Avoiding regression in project governance

On 2015-03-10 14:42:18 -0400 (-0400), Russell Bryant wrote: [...] > As to specific tags, I refer back to this: > > http://governance.openstack.org/reference/incubation-integration-requirements.html > > We worked pretty hard to come up with useful things for projects > to aim for. In fact, we cons

Re: [openstack-dev] Controlling data sent to client

On 03/10/2015 11:45 AM, Omkar Joshi wrote: Hi, I am using open stack swift server. Now say multiple clients are requesting 5GB object from server. The rate at which server can push data into server socket is much more than the rate at which client can read it from proxy server. Is there configur

Re: [openstack-dev] Avoiding regression in project governance

On 03/10/2015 02:56 PM, Thierry Carrez wrote: > Russell Bryant wrote: >> One point of clarification: >> >> On 03/10/2015 02:28 PM, Gabriel Hurley wrote: >>> Even more concerning is the sentiment of "projects we want to >>> consciously drop" from Russell's original email. >> >> This was in reference

Re: [openstack-dev] Avoiding regression in project governance

Dissolving the integrated release without having a solid plan and replacement is difficult to communicate to people who depend on OpenStack. We’re struggling on that front. That said, I’m still optimistic about project structure reform and think it could be beneficial to the development communi

Re: [openstack-dev] Controlling data sent to client

Thanks Rick for a quick reply. Are you asking about the rate at which data might come from the object server(s) to the proxy and need to be held on the proxy while it is sent-on to the clients? Yes... the object sever will push faster and therefore accumulation of data in proxy server will be

Re: [openstack-dev] [neutron][vpnaas] VPNaaS Subteam meetings

Given the votes so far, the proposal is to move the meeting time to 1600 UTC on Tuesday. The channel is openstack-meeting-3 (as the only one available). In addition, the meeting will be "on-demand", so if you want to have a meeting, send email to this mailing list, at least 24 hours before the mee

Re: [openstack-dev] [stacktach] [oslo] stachtach -> kombu -> pika ??

Maybe the plan for oslo.messaging should be to make it resolve some of the operators issues first ;-) https://etherpad.openstack.org/p/PHL-ops-rabbit-queue https://etherpad.openstack.org/p/PHL-ops-large-deployments I'd rather think we should like ummm, be thinking about fixing issues instead

Re: [openstack-dev] Avoiding regression in project governance

On 10/03/15 12:29, Russell Bryant wrote: I feel that we're at a very vulnerable part of this transition. We've abolished the incubation process and integrated release. We've established a fairly low bar for new projects [2]. However, we have not yet approved*any* tags other than the one that

Re: [openstack-dev] [stacktach] [oslo] stachtach -> kombu -> pika ??

No, we're adding this to Yagi first and perhaps Notabene later. We don't need rpc support, so it's too big a change for us to take on. From: gordon chung Sent: Tuesday, March 10, 2015 3:58 PM To: OpenStack Development Mailing List not for usage questions Subjec

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 1:32 PM, Jay Pipes wrote: > On 03/10/2015 02:28 PM, Gabriel Hurley wrote: > >> Blocking the acceptance of new projects seems punitive and against >> the spirit of the big tent. Classification (tagging) can be done at >> any point, and is hardly fixed in stone. You can refi

Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with Ceilometer deployments - Feedback requested

sorry, i apparently don't know how to format emails... cheers, gord From: [email protected] To: [email protected]; [email protected] Date: Tue, 10 Mar 2015 16:05:47 -0400 Subject: Re: [openstack-dev] [Openstack-operators] [Ceilometer] Real world experience with

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

Hi Anne, Thanks for the quick answer. One thing that still not clear for me is about the documentation that is currently there. Will it be removed (converted to the resumed version) in Kilo? If so what are the milestones for that? Erlon On Tue, Mar 10, 2015 at 10:48 AM, Anne Gentle wrote: > >

[openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

There was a broken wheel built when testtools 1.7.0 was released. The wheel was missing the _compat2x.py file used for 2.x only syntax in exception handling, for an unknown reason. (We know how to trigger it - build the wheel with Python 3.4). The wheel has been removed from PyPI and anyone instal

Re: [openstack-dev] Driver documentation for Kilo [cinder] [neutron] [nova] [trove]

On Tue, Mar 10, 2015 at 3:35 PM, Erlon Cruz wrote: > Hi Anne, > > Thanks for the quick answer. One thing that still not clear for me is > about the documentation that is currently there. Will it be removed > (converted to the resumed version) in Kilo? If so what are the milestones > for that? >

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter wrote: > On 10/03/15 12:29, Russell Bryant wrote: > >> >> I feel that we're at a very vulnerable part of this transition. We've >> abolished the incubation process and integrated release. We've >> established a fairly low bar for new projects [2].

Re: [openstack-dev] [all] Testtools 1.7.0 may error if you installed it before reading this email

Great to hear that this has been addressed, as this impacted a few tests in keystone. (but why was the fix not released as 1.7.1?) On Tue, Mar 10, 2015 at 4:10 PM, Robert Collins wrote: > There was a broken wheel built when testtools 1.7.0 was released. The > wheel was missing the _compat2x.py

[openstack-dev] [qa] Question about is_admin_available()

In the process of writing a unit test for this I discovered that it can call out to keystone for a token with some configurations through the call to get_configured_credentials. This surprised me since I thought it would just check for the necessary admin credentials in either tempest.conf or a

Re: [openstack-dev] new failures running Barbican functional tests

Thanks for the insight, other Doug. :) It appears that this is in part due to the fact that Tempest has not yet updated to oslo_log and is still using incubator oslo.log. Can someone from the Tempest team chime in on what the status of migrating to oslo_log is? It’s imperative for us to fix o

Re: [openstack-dev] [python-novaclient] Better wording for secgroup-*-default-rules? help text

On Mar 10, 2015, at 7:32, Chris St. Pierre wrote: > I've just filed a bug on the confusing wording of help text for the > secgroup-{add,delete,list}-default-rules? commands: > https://bugs.launchpad.net/python-novaclient/+bug/1430354 > > As I note in the bug, though, I'm not sure the best way

Re: [openstack-dev] [qa] Question about is_admin_available()

Preventing the token request could be an improvement, as the token request might not be expected to happen in that method. If the token cannot be obtained because credentials are wrong, an exception will be triggered. If we removed the token request from is_admin_available, this scenario would be

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015, at 05:27 PM, Joe Gordon wrote: > On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter wrote: > > > On 10/03/15 12:29, Russell Bryant wrote: > > > >> > >> I feel that we're at a very vulnerable part of this transition. We've > >> abolished the incubation process and integrated re

Re: [openstack-dev] Avoiding regression in project governance

On Tue, Mar 10, 2015 at 3:00 PM, Doug Hellmann wrote: > > > On Tue, Mar 10, 2015, at 05:27 PM, Joe Gordon wrote: > > On Tue, Mar 10, 2015 at 12:30 PM, Zane Bitter > wrote: > > > > > On 10/03/15 12:29, Russell Bryant wrote: > > > > > >> > > >> I feel that we're at a very vulnerable part of this t

Re: [openstack-dev] Avoiding regression in project governance

Russell Bryant writes: > Part of the change is to recognize more projects as being part of the > OpenStack community. Another critical part was replacing the integrated > release with a set of tags. A project would be given a tag if it meets > some defined set of criteria. ... > I can't think o

Re: [openstack-dev] Avoiding regression in project governance

Joe Gordon writes: > After watching the TC meeting, and double checking with the meeting notes > [0], it looks like the magnum vote was deferred to next week. But what > concerns me is the lack of action items assigned that will help make sure > next weeks discussion isn't just a repeat of what h

  1   2   >