Re: [openstack-dev] [Fuel] Fuel Plugins, First look; Whats Next?

On Mon, Nov 24, 2014 at 4:40 AM, Evgeniy L wrote: > Hi Andrew, > > Comments inline. > Also could you please provide a link on OpenStack upgrade feature? > It's not clear why do you need it as a plugin and how you are going > to deliver this feature. > > On Sat, Nov 22, 2014 at 4:23 AM, Andrew Wood

[openstack-dev] [sahara] Asia friendly IRC meeting time

Hi All, I'd like to propose a time change to the weekly IRC meeting to make it more convenient for people from Asia to attend. As you might be aware, we here at Intel in China have a few people started working on Sahara actively since Juno release. I also noticed that there are contributions from

Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster

Hi, Thanks for your advice. I understood that the logs are necessary to judge whether no failure on object-replicator. And also, I thought that the recon info of object-replicator having failure (just like the recon info of account-replicator and container-replicator) is useful. Are there any

[openstack-dev] [Glance] Weekly-meeting time change.

Hi all, Happy Thanksgiving (in advance)! The meeting on Nov. 27th has been cancelled duly. So, we will be having the next meeting on Thursday, December 4th at 1400UTC. The meeting after will be on Dec 11th at 1500 UTC. (channel: #openstack-meeting-4 ) Please find the new alternating time slots

[openstack-dev] [gantt] Scheduler sub-group meeting agenda 11/25

Meeting on #openstack-meeting at 1500 UTC (8:00AM MST) 1) Status on cleanup work - https://wiki.openstack.org/wiki/Gantt/kilo -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mail

Re: [openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

> On Nov 24, 2014, at 7:32 PM, Michael Still wrote: > > Interesting. I hadn't seen consistency between the two databases as > trumping doing this less horribly, but it sounds like its more of a > thing that I thought. it really depends on what you need to do. if you need to get a result set of

Re: [openstack-dev] [sahara] Discussion on cm_api for global requirement

Hi Trevor, Thank you for bringing this to the IRC meeting! I agree with you guys' conclusion. Patch 136697 has been submitted to address it in Sahara document. Thanks, Zhidong On Tue, Nov 25, 2014 at 2:22 AM, Trevor McKay wrote: > Hello all, > > at our last Sahara IRC meeting we started disc

Re: [openstack-dev] [all] removing XML testing completely from Tempest

> -Original Message- > From: Sean Dague [mailto:s...@dague.net] > Sent: Monday, November 24, 2014 10:57 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [all] removing XML testing completely from Tempest > > Having XML payloads was never a universal part of OpenStack

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

On 19 November 2014 at 11:31, Mark McClain wrote: > All- > > Over the last several months, the members of the Networking Program have > been discussing ways to improve the management of our program. When the > Quantum project was initially launched, we envisioned a combined service > that include

Re: [openstack-dev] [Nova] Tracking Kilo priorities

> On 25 Nov 2014, at 02:35, Michael Still wrote: > > On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti > wrote: >> Hi Michael, >> >>> On 25 Nov 2014, at 01:57, Michael Still wrote: >>> >>> First off, sorry for the slow reply. I was on vacation last week. >>> >>> The project priority lis

Re: [openstack-dev] [Nova] Tracking Kilo priorities

On Tue, Nov 25, 2014 at 11:23 AM, Alessandro Pilotti wrote: > Hi Michael, > >> On 25 Nov 2014, at 01:57, Michael Still wrote: >> >> First off, sorry for the slow reply. I was on vacation last week. >> >> The project priority list was produced as part of the design summit, >> and reflects nova's n

Re: [openstack-dev] opnfv proposal on DR capability enhancement on OpenStack Nova

Hi all, We have updated our proposal to reflect more details on our proposal. The opnfv wiki link should be public for now: https://wiki.opnfv.org/collaborative_development_projects/rescuer We currently limit the scope of the project to provide VM DR state, so that we could make a K release targe

Re: [openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

On Tue, Nov 25, 2014 at 11:14 AM, Mike Bayer wrote: > >> On Nov 24, 2014, at 5:20 PM, Michael Still wrote: >> >> Heya, >> >> Review https://review.openstack.org/#/c/135644/4 proposes the addition >> of a new database for our improved implementation of cells in Nova. >> However, there's an outstan

Re: [openstack-dev] [Nova] Tracking Kilo priorities

Hi Michael, > On 25 Nov 2014, at 01:57, Michael Still wrote: > > First off, sorry for the slow reply. I was on vacation last week. > > The project priority list was produced as part of the design summit, > and reflects nova's need to pay down technical debt in order to keep > meeting our users

Re: [openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

> On Nov 24, 2014, at 5:20 PM, Michael Still wrote: > > Heya, > > Review https://review.openstack.org/#/c/135644/4 proposes the addition > of a new database for our improved implementation of cells in Nova. > However, there's an outstanding question about how to handle soft > delete of rows --

Re: [openstack-dev] [Nova] Tracking Kilo priorities

First off, sorry for the slow reply. I was on vacation last week. The project priority list was produced as part of the design summit, and reflects nova's need to pay down technical debt in order to keep meeting our users needs. So, whilst driver changes are important, they doesn't belong on that

[openstack-dev] [Horizon]

I am pleased to nominate Thai Tran and Cindy Lu to horizon-core. Both Thai and Cindy have been contributing significant numbers of high quality reviews during Juno and Kilo cycles. They are consistently among the top non-core reviewers. They are also responsible for a significant number of patches

Re: [openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

On Tue, 2014-11-25 at 09:20 +1100, Michael Still wrote: > - we do what we do in the current nova database -- we have a deleted > column, and we set it to true when we delete the instance. Actually, current nova uses the oslo.db.sqlalchemy.models.SoftDeleteMixin class, which defines the columns 'd

Re: [openstack-dev] [neutron] - the setup of a DHCP sub-group

Don, Could the spec linked to your BP be moved to the specs repository? I'm hesitant to start reading it as a google doc when I know I'm going to want to make comments and ask questions. Carl On Thu, Nov 13, 2014 at 9:19 AM, Don Kehn wrote: > If this shows up twice sorry for the repeat: > > Arm

[openstack-dev] [Octavia] Meeting on Wednesday, Nov. 26th cancelled

Hi folks! Since: * The agenda contains no earth-shattering updates (ie. just going over review progress) * Nearly all the people working on Octavia are US-based * The meeting is in the afternoon for most folks * Wednesday is the day before a long holiday weekend and many employers give their empl

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

My impression is that the statuses of each entity will be shown on a detailed info request of a loadbalancer. The root level objects would not have any statuses. For example a user makes a GET request to /loadbalancers/{lb_id} and the status of every child of that load balancer is show in a "stat

Re: [openstack-dev] [api] APIImpact flag for specs

I’ve also added APIImpact flag info to the Git Commit Messages page [1]. Everett [1] https://wiki.openstack.org/wiki/GitCommitMessages#Including_external_references On Nov 19, 2014, at 5:23 PM, Everett Toews mailto:everett.to...@rackspace.com>> wrote: On Nov 13, 2014, at 2:06 PM, Everett To

[openstack-dev] [Nova] Handling soft delete for instance rows in a new cells database

Heya, Review https://review.openstack.org/#/c/135644/4 proposes the addition of a new database for our improved implementation of cells in Nova. However, there's an outstanding question about how to handle soft delete of rows -- we believe that we need to soft delete for forensic purposes. This i

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

On Tue, Nov 25, 2014 at 7:06 AM, Jay Pipes wrote: > On 11/24/2014 03:11 PM, Joshua Harlow wrote: > >> Dan Smith wrote: >> >>> 3. vish brought up one draw back of versioned objects: the difficulty in cherry picking commits for stable branches - Is this a show stopper?. >>> >>> After some

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

On Nov 24, 2014, at 13:06, Jay Pipes wrote: > That said, I don't think it's wise to make oslo-versionedobjects be a totally > new thing. I think we should use nova.objects as the base of a new > oslo-versionedobjects library, and we should evolve oslo-versionedobjects > slowly over time, event

[openstack-dev] [Ironic] Weekly Status Update

Hi all, Ironic has decided to email a weekly status report for all subteams. This is the inaugural issue of that. :) This is and will be a copy and paste from the Ironic whiteboard.[0] Testing (adam_g) (deva) - make Ironic voting -- needs to be rebased again, but has been approved Bugs (dta

Re: [openstack-dev] [Ironic] Cleaning up spec review queue.

Thank you all for the reply's to this thread. I have now set all of the listed spec's to an abandoned state, Please note that any review can be recovered quickly but clicking the "Restore Change" button. If one of the listed spec's is restored please be sure to re-target to the Kilo cycle. Thank y

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

On 11/24/2014 03:11 PM, Joshua Harlow wrote: Dan Smith wrote: 3. vish brought up one draw back of versioned objects: the difficulty in cherry picking commits for stable branches - Is this a show stopper?. After some discussion with some of the interested parties, we're planning to add a third

Re: [openstack-dev] [swift] a way of checking replicate completion on swift cluster

replication logs On Thu, Nov 20, 2014 at 9:32 PM, Matsuda, Kenichiro < matsuda_keni...@jp.fujitsu.com> wrote: > Hi, > > Thank you for the info. > > I was able to get replication info easily by swift-recon API. > But, I wasn't able to judge whether no failure from recon info of > object-replicator

Re: [openstack-dev] [neutron][lbaas] Shared Objects in LBaaS - Use Cases that led us to adopt this.

Hi Samuel, We've actually been avoiding having a deeper discussion about status in Neutron LBaaS since this can get pretty hairy as the back-end implementations get more complicated. I suspect managing that is probably one of the bigger reasons we have disagreements around object sharing. Perhaps

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

Doug Hellmann wrote: On Nov 24, 2014, at 12:57 PM, Mike Bayer wrote: On Nov 24, 2014, at 12:40 PM, Doug Hellmann wrote: This is a good point. I’m not sure we can say “we’ll only use explicit/implicit async in certain cases" because most of our apps actually mix the cases. We have WSGI app

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

On Nov 24, 2014, at 12:57 PM, Mike Bayer wrote: > >> On Nov 24, 2014, at 12:40 PM, Doug Hellmann wrote: >> >> >> This is a good point. I’m not sure we can say “we’ll only use >> explicit/implicit async in certain cases" because most of our apps actually >> mix the cases. We have WSGI apps

Re: [openstack-dev] [nova] deleting the pylint test job

This job was always experimental IIRC, and the original author hasn't been around in a while. I agree we should remove it. Michael On Tue, Nov 25, 2014 at 4:52 AM, Sean Dague wrote: > The pylint test job has been broken for weeks, no one seemed to care. > While waiting for other tests to return

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

Dan Smith wrote: 3. vish brought up one draw back of versioned objects: the difficulty in cherry picking commits for stable branches - Is this a show stopper?. After some discussion with some of the interested parties, we're planning to add a third .z element to the version numbers and use that

Re: [openstack-dev] [Fuel] fuel master monitoring

One of the selling points of tripleo is to reuse as much as possible from the cloud, to make it easier to deploy. While monasca may be more complicated, if it ends up being a component everyone learns, then its not as bad as needing to learn two different monitoring technologies. You could say t

[openstack-dev] [Oslo][Neutron] Fork() safety and oslo.messaging

Hi all, As far as oslo.messaging is concerned, should it be possible for the main application to safely os.fork() when there is already an active connection to a messaging broker? I ask because I'm hitting what appears to be fork-related issues with the new AMQP 1.0 driver. I think the same prob

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

> 3. vish brought up one draw back of versioned objects: the difficulty in > cherry picking commits for stable branches - Is this a show stopper?. After some discussion with some of the interested parties, we're planning to add a third .z element to the version numbers and use that to handle backp

[openstack-dev] [Infra] Meeting Tuesday November 25th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday November 25th, at 19:00 UTC in #openstack-meeting Meeting agenda available here: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting (anyone is welcome to to add agenda items) Everyone intereste

Re: [openstack-dev] Launching VM in multi-node setup

Danny- Availability zones and host aggregates are your friend. For more detail check out: http://docs.openstack.org/openstack-ops/content/scaling.html -- Don Dugger "Censeo Toto nos in Kansa esse decisse." - D. Gale Ph: 303/443-3786 From: Danny Choi (dannchoi) [mailto:dannc...

[openstack-dev] [neutron] Updating template spec to include "IPV6 Impact"

I proposed a template change today [1] which adds an "IPV6 Impact" section into the template specification. This was done after some discussion on the "Kilo Priorities" spec [2] around IPV6. Given how important IPV6 is, it's my opinion we should ensure specifications for Kilo and beyond think about

Re: [openstack-dev] [all] Versioned objects cross project sessions next steps

On 11/13/2014 01:12 AM, Robert Collins wrote: On 11 November 2014 13:30, Angus Salkeld wrote: Hi all I just wanted to make sure we are all under the same understanding of the outcomes and what the next steps for the versioned objects session are. 1. There is a lot of interest in other project

[openstack-dev] [sahara] Discussion on cm_api for global requirement

Hello all, at our last Sahara IRC meeting we started discussing whether or not to add a global requirement for cm_api.py https://review.openstack.org/#/c/130153/ One issue (but not the only issue) is that cm_api is not packaged for Fedora, Centos, or Ubuntu currently. The global requirements

Re: [openstack-dev] [nova] Proposal new hacking rules

On 11/24/2014 01:02 PM, pcrews wrote: On 11/24/2014 09:40 AM, Ben Nemec wrote: On 11/24/2014 08:50 AM, Matthew Gilliard wrote: 1/ assertFalse() vs assertEqual(x, False) - these are semantically different because of python's notion of truthiness, so I don't think we ought to make this a rule. 2

[openstack-dev] Launching VM in multi-node setup

Hi, In a multi-node setup with multiple Compute nodes, is there a way to control where a VM will reside when launching a VM? E.g. I would like to have VM-1 at Compute-1, VM-2 at Compute-2, etc… Thanks, Danny ___ OpenStack-dev mailing list OpenStack-dev

Re: [openstack-dev] [nova] deleting the pylint test job

On Mon, Nov 24, 2014 at 9:52 AM, Sean Dague wrote: > The pylint test job has been broken for weeks, no one seemed to care. > While waiting for other tests to return today I looked into it and > figured out the fix. > > However, because of nova objects pylint is progressively less and less > usefu

Re: [openstack-dev] [nova] Proposal new hacking rules

On 11/24/2014 09:40 AM, Ben Nemec wrote: On 11/24/2014 08:50 AM, Matthew Gilliard wrote: 1/ assertFalse() vs assertEqual(x, False) - these are semantically different because of python's notion of truthiness, so I don't think we ought to make this a rule. 2/ expected/actual - incorrect failure m

Re: [openstack-dev] [nova] deleting the pylint test job

> However, because of nova objects pylint is progressively less and less > useful. So the fact that no one else looked at it means that people > didn't seem to care that it was provably broken. I think it's better > that we just delete the jobs and save a node on every nova patch instead. Agreed.

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

> On Nov 24, 2014, at 12:40 PM, Doug Hellmann wrote: > > > This is a good point. I’m not sure we can say “we’ll only use > explicit/implicit async in certain cases" because most of our apps actually > mix the cases. We have WSGI apps that send RPC messages and we have other > apps that recei

Re: [openstack-dev] [all] removing XML testing completely from Tempest

+1 to cleanup. -- dims On Mon, Nov 24, 2014 at 12:50 PM, Monty Taylor wrote: > On 11/24/2014 12:36 PM, Lance Bragstad wrote: >> We are in the process of removing XML support from Keystone [1] and have >> provided >> configuration options to Tempest for testing XML in older releases [2]. >> Howev

Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?

On 11/24/2014 10:14 AM, Drew Fisher wrote: > > > On 11/17/14 10:27 PM, Duncan Thomas wrote: >> Is the new driver drop-in compatible with the old one? IF not, can >> existing systems be upgraded to the new driver via some manual steps, or >> is it basically a completely new driver with similar fun

[openstack-dev] [nova] deleting the pylint test job

The pylint test job has been broken for weeks, no one seemed to care. While waiting for other tests to return today I looked into it and figured out the fix. However, because of nova objects pylint is progressively less and less useful. So the fact that no one else looked at it means that people d

Re: [openstack-dev] [all] removing XML testing completely from Tempest

On 11/24/2014 12:36 PM, Lance Bragstad wrote: > We are in the process of removing XML support from Keystone [1] and have > provided > configuration options to Tempest for testing XML in older releases [2]. > However, the > identity client is still tightly coupled to XML test cases. We can either >

Re: [openstack-dev] [oslo] proposed library releases for next week

After the Oslo meeting today, most of the folks preparing releases met separately and decided to wait to create any new releases until the stable branches are ready. We need devstack to install Oslo libs from packages (merged) and to cap the Oslo requirements. Sean is going to raise the latter

Re: [openstack-dev] [nova] Proposal new hacking rules

On 11/24/2014 08:50 AM, Matthew Gilliard wrote: > 1/ assertFalse() vs assertEqual(x, False) - these are semantically > different because of python's notion of truthiness, so I don't think > we ought to make this a rule. > > 2/ expected/actual - incorrect failure messages have cost me more time > t

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

On Nov 24, 2014, at 11:30 AM, Jay Pipes wrote: > On 11/24/2014 10:43 AM, Mike Bayer wrote: >>> On Nov 24, 2014, at 9:23 AM, Adam Young wrote: >>> For pieces such as the Nova compute that talk almost exclusively on >>> the Queue, we should work to remove Monkey patching and use a clear >>> progr

Re: [openstack-dev] [all] removing XML testing completely from Tempest

We are in the process of removing XML support from Keystone [1] and have provided configuration options to Tempest for testing XML in older releases [2]. However, the identity client is still tightly coupled to XML test cases. We can either fix the 309 test cases that use the XML identity client or

Re: [openstack-dev] [Fuel] Let's use additional prefixes in threads

On 11/24/2014 12:04 PM, Vladimir Kuklin wrote: [Fuel][Library] for compatibility with other projects. Let's negotiate the list of prefixes and populate them on our wiki so that everyone can configure his filters. ++ -jay ___ OpenStack-dev mailing li

Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night

Hello, On Fri, Nov 21, 2014 at 10:10 PM, Mike Bayer wrote: > 1. read about the new features, particularly the branch support, and > please let me know of any red flags/concerns you might have over the coming > implementation, at > http://alembic.readthedocs.org/en/latest/tutorial.html#running-ba

Re: [openstack-dev] [Fuel] Let's use additional prefixes in threads

[Fuel][Library] for compatibility with other projects. Let's negotiate the list of prefixes and populate them on our wiki so that everyone can configure his filters. On Mon, Nov 24, 2014 at 7:26 PM, Jay Pipes wrote: > On 11/24/2014 11:01 AM, Vladimir Kuklin wrote: > >> Fuelers >> >> I am writing

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

On 11/24/2014 10:43 AM, Mike Bayer wrote: On Nov 24, 2014, at 9:23 AM, Adam Young wrote: For pieces such as the Nova compute that talk almost exclusively on the Queue, we should work to remove Monkey patching and use a clear programming model. If we can do that within the context of Eventlet, g

Re: [openstack-dev] [Fuel] Let's use additional prefixes in threads

On 11/24/2014 11:01 AM, Vladimir Kuklin wrote: Fuelers I am writing to you to suggest adding prefixes for Fuel subprojects/ as it becomes more and more difficult to read all the emails in mailing lists. Adding these prefixes should significantly improve ability of our engineers to filter out ema

[openstack-dev] [mistral] Team meeting minutes/log - 11/24/2014

Thanks for joining us today, Here are the links to the meeting minutes and full log: - Minutes - http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-24-16.00.html - Full log - *http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-11-24-16.00.log.html

Re: [openstack-dev] [Horizon] proposal: alternating weekly meeting time [doodle poll created]

Le 24/11/2014 04:20, Richard Jones a écrit : > Thanks everyone, I've closed the poll. I'm sorry to say that there's no > combination of two timeslots which allows everyone to attend a meeting. > Of the 25 respondents, the best we can do is cater for 24 of you. > > Optimising for the maximum numb

[openstack-dev] [Fuel] Let's use additional prefixes in threads

Fuelers I am writing to you to suggest adding prefixes for Fuel subprojects/ as it becomes more and more difficult to read all the emails in mailing lists. Adding these prefixes should significantly improve ability of our engineers to filter out emails they are not interested in, e.g. UI implement

[openstack-dev] [mistral] Team meeting - 11/24/2014

This is a reminder about our team meeting scheduled for today 16.00 UTC. Agenda: - Review action items - Paris Summit results - Current status (progress, issues, roadblocks, further plans) - Release 0.2 progress - Open discussion -- Best Regards, Nikolay

Re: [openstack-dev] [Fuel] fuel master monitoring

And it all started out with simple free disk space monitoring :) I created a document https://etherpad.openstack.org/p/fuel-master-monitoring Let's write what exactly we want to monitor and what actions to take. Then it would be easier to decide which system we want. P. On 11/24/2014 04:32

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

> On Nov 24, 2014, at 9:23 AM, Adam Young wrote: > > > > For pieces such as the Nova compute that talk almost exclusively on the > Queue, we should work to remove Monkey patching and use a clear programming > model. If we can do that within the context of Eventlet, great. If we need > to

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

> On Nov 23, 2014, at 9:24 PM, Donald Stufft wrote: > > > There’s a long history of implicit context switches causing buggy software > that breaks. As far as I can tell the only downsides to explicit context > switches that don’t stem from an inferior interpreter seem to be “some > particula

Re: [openstack-dev] [Fuel] fuel master monitoring

Rob Basham Cloud Systems Software Architecture 971-344-1999 Tomasz Napierala wrote on 11/24/2014 06:42:39 AM: > From: Tomasz Napierala > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 11/24/2014 06:46 AM > Subject: Re: [openstack-dev] [Fuel] fuel master monito

Re: [openstack-dev] [devstack] external plugin support for Devstack

On 11/24/2014 10:17 AM, Chmouel Boudjnah wrote: > > On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague > wrote: > > We should also make this something which is gate friendly. I think the > idea had been that if projects included a /devstack/ directory in them, > when

Re: [openstack-dev] [devstack] external plugin support for Devstack

On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague wrote: > We should also make this something which is gate friendly. I think the > idea had been that if projects included a /devstack/ directory in them, > when assembling devstack gate, that would be automatically dropped into > devstack's extra.d dire

Re: [openstack-dev] [cinder] Anyone Using the Open Solaris ZFS Driver?

On 11/17/14 10:27 PM, Duncan Thomas wrote: > Is the new driver drop-in compatible with the old one? IF not, can > existing systems be upgraded to the new driver via some manual steps, or > is it basically a completely new driver with similar functionality? The driver in san/solaris.py focuses en

Re: [openstack-dev] [Neutron] Bug day

Great progress! Thanks for this huge effort. Edgar From: Eugene Nikanorov mailto:enikano...@mirantis.com>> Reply-To: OpenStack Development Mailing List mailto:openstack-dev@lists.openstack.org>> Date: Monday, November 24, 2014 at 1:52 AM To: OpenStack Development Mailing List mailto:openstack-d

Re: [openstack-dev] [nova] Proposal new hacking rules

Matthew Gilliard said on Mon, Nov 24, 2014 at 02:50:08PM +: > 1/ assertFalse() vs assertEqual(x, False) - these are semantically > different because of python's notion of truthiness, so I don't think > we ought to make this a rule. > 2/ expected/actual - I don't see any reason not to try to imp

Re: [openstack-dev] [nova] Proposal new hacking rules

1/ assertFalse() vs assertEqual(x, False) - these are semantically different because of python's notion of truthiness, so I don't think we ought to make this a rule. 2/ expected/actual - incorrect failure messages have cost me more time than I should admit to. I don't see any reason not to try to

Re: [openstack-dev] [Fuel] fuel master monitoring

> On 24 Nov 2014, at 11:09, Sergii Golovatiuk wrote: > > Hi, > > monasca looks overcomplicated for the purposes we need. Also it requires > Kafka which is Java based transport protocol. > I am proposing Sensu. It's architecture is tiny and elegant. Also it uses > rabbitmq as transport so we w

Re: [openstack-dev] [devstack] external plugin support for Devstack

On 11/24/2014 08:56 AM, Chmouel Boudjnah wrote: > Hello, > > Thanks to the work of Dean and others we have a pretty solid > plugins/extras support in Devstack. People can add new features in > devstack within just a single file and that add a whole new feature or > driver to devstack. > > It seem

[openstack-dev] [Neutron][api] Extensions, micro-version and the evolution of the API

Hi, As most of you surely know the proposal for micro versioning in Nova [1] has been approved for Kilo. I am sure you are aware that a similar proposal has bee discussed for Neutron at the design summit. Considering the direction taken by nova, and the fact that neutron extensions are becoming u

Re: [openstack-dev] [oslo] Add a new aiogreen executor for Oslo Messaging

On 11/23/2014 06:13 PM, Robert Collins wrote: On WSGI - if we're in an asyncio world, I don't think WSGI has any relevance today - it has no async programming model. While is has incremental apis and supports generators, thats not close enough to the same thing: so we're going to have to port our

Re: [openstack-dev] [tempest] How to run tempest tests

Angelo, One more way to run Tempest is to run it via Rally. Rally will take care about installation, generating tempest.conf, running tempest, parsing & storing output results. Here is manual: https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/ As a bonus you'll get abil

Re: [openstack-dev] [tempest] How to run tempest tests

Hi, I cannot comment on the best practice. But I can point to you a few more methods and links. 1. https://dague.net//presentations/tempest-101/#/ 2. http://www.slideshare.net/kamesh001/open-stack-qa-and-tempest?next_slideshow=1 3. https://docs.google.com/presentation/d/1M3XhAco_0u7NZQn3Gz53z9VO

Re: [openstack-dev] [all] removing XML testing completely from Tempest

On 11/24/2014 08:56 AM, Sean Dague wrote: Having XML payloads was never a universal part of OpenStack services. During the Icehouse release the TC declared that being an OpenStack service requires having a JSON REST API. Projects could do what they wanted beyond that. Lots of them deprecated and

[openstack-dev] [devstack] external plugin support for Devstack

Hello, Thanks to the work of Dean and others we have a pretty solid plugins/extras support in Devstack. People can add new features in devstack within just a single file and that add a whole new feature or driver to devstack. It seems that there is quite a bit of people who wants to have those ex

[openstack-dev] [all] removing XML testing completely from Tempest

Having XML payloads was never a universal part of OpenStack services. During the Icehouse release the TC declared that being an OpenStack service requires having a JSON REST API. Projects could do what they wanted beyond that. Lots of them deprecated and have been removing the XML cruft since then.

Re: [openstack-dev] [stable] Organizational changes to support stable branches

OK, since there was no disagreement I pushed the changes to: https://wiki.openstack.org/wiki/StableBranch We'll get started setting up project-specific stable-maint teams ASAP. Cheers, Thierry Carrez wrote: > TL;DR: > Every project should designate a Stable branch liaison. > > Hi everyone, > >

Re: [openstack-dev] [Fuel] Plugins improvement

Hi Dmitry, Our current validation implementation is based on jsonschema, we will figure out how to hack/configure it to provide more human readable message Thanks, On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov wrote: > That was my fault. I did not expect that timeout parameter is a mandatory >

[openstack-dev] [nova] Integration with Ceph

Hi, As you know we can use Ceph as ephemeral storage in nova. But we have some problems with its integration. First of all, total storage of compute nodes is calculated incorrectly. (more details here https://bugs.launchpad.net/nova/+bug/1387812). I want to fix this problem. Now size of total stora

Re: [openstack-dev] [Fuel] Fuel Plugins, First look; Whats Next?

Hi Andrew, Comments inline. Also could you please provide a link on OpenStack upgrade feature? It's not clear why do you need it as a plugin and how you are going to deliver this feature. On Sat, Nov 22, 2014 at 4:23 AM, Andrew Woodward wrote: > So as part of the pumphouse integration, I've sta

Re: [openstack-dev] Where should Schema files live?

>From: Eoghan Glynn [egl...@redhat.com] Friday, November 21, 2014 11:03 AM >> >> Some problems / options: >> >> a. Unlike Python, there is no simple pip install for text files. No >> >> version control per se. Basically whatever we pull from the repo. The >> >> problem with a git clone is we need t

Re: [openstack-dev] [Fuel] Plugins improvement

> I did not expect that timeout parameter is a mandatory requirement for task UX is obviously has to be improved here. Can we make a clear error, if there is no required parameter, instead of throwing unclear exception? On Mon, Nov 24, 2014 at 2:34 PM, Dmitry Ukov wrote: > That was my fault. I

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

guys, there is already pxz utility in ubuntu repos. let's test it On Mon, Nov 24, 2014 at 2:32 PM, Bartłomiej Piotrowski < bpiotrow...@mirantis.com> wrote: > On 24 Nov 2014, at 12:25, Matthew Mosesohn wrote: > > I did this exercise over many iterations during Docker container > > packing and fou

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

Mattherw, Dmitry I would suggest to use: 1) multi-threaded utilities 2) use xz for small snapshots (<1gb) and lrzip for bigger snapshots On Mon, Nov 24, 2014 at 2:25 PM, Matthew Mosesohn wrote: > I did this exercise over many iterations during Docker container > packing and found that as long a

Re: [openstack-dev] [Fuel] Plugins improvement

That was my fault. I did not expect that timeout parameter is a mandatory requirement for task. Every thing works perfectly fine. Thanks for the help. On Mon, Nov 24, 2014 at 3:05 PM, Tatyana Leontovich < tleontov...@mirantis.com> wrote: > Guys, > task like > - role: ['controller'] > stage: post_

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

On 24 Nov 2014, at 12:25, Matthew Mosesohn wrote: > I did this exercise over many iterations during Docker container > packing and found that as long as the data is under 1gb, it's going to > compress really well with xz. Over 1gb and lrzip looks more attractive > (but only on high memory systems)

Re: [openstack-dev] [Fuel] Plugins improvement

I tried to reproduce this behavior with tasks.yaml: # Deployment is required for controllers - role: ['controller'] stage: post_deployment type: puppet parameters: puppet_manifest: site.pp puppet_modules: "puppet/:/etc/puppet/modules" timeout: 360 And actually plugin was built s

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

I did this exercise over many iterations during Docker container packing and found that as long as the data is under 1gb, it's going to compress really well with xz. Over 1gb and lrzip looks more attractive (but only on high memory systems). In reality, we're looking at log footprints from OpenStac

Re: [openstack-dev] [Fuel] Change diagnostic snapshot compression algoritm

IMO, we should get a bunch of snapshots and decide which compression to use according to the results of an experiment. XZ compression takes much longer, so you will need to use parallel xz compression utility. On Fri, Nov 21, 2014 at 9:09 PM, Tomasz Napierala wrote: > > > On 21 Nov 2014, at 16:5

Re: [openstack-dev] [Fuel] Plugins improvement

Guys, task like - role: ['controller'] stage: post_deployment type: puppet parameters: puppet_manifest: puppet/site.pp puppet_modules: puppet/modules/ timeout: 360 works fine for me, so I believe your task should looks like cat tasks.yaml # This tasks will be applied on controller nodes, # here y

Re: [openstack-dev] [Fuel] Plugins improvement

Unfortunately this does not work cat tasks.yaml # This tasks will be applied on controller nodes, # here you can also specify several roles, for example # ['cinder', 'compute'] will be applied only on # cinder and compute nodes - role: ['controller'] stage: post_deployment type: puppet param

Re: [openstack-dev] [Fuel] Plugins improvement

Hi, according to [1] you should be able to use: puppet_modules: "puppet/:/etc/puppet/modules/" This is valid string yaml parameter that should be parsed just fine. [1] https://github.com/stackforge/fuel-web/blob/master/tasklib/tasklib/actions/puppet.py#L61-L62 Regards -- Alex On Mon, Nov 24,

  1   2   >