Re: [openstack-dev] [Ironic] (Non-)consistency of the Ironic hash ring implementation

On 09/08/2014 06:22 AM, Robert Collins wrote: On 8 September 2014 05:57, Nejc Saje wrote: \ That generator API is pretty bad IMO - because it means you're very heavily dependent on gc and refcount behaviour to keep things clean - and there isn't (IMO) a use case for walking the entire ring fr

Re: [openstack-dev] [neutron][cisco] Cisco Nexus requires patched ncclient

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 24/08/14 20:40, Maru Newby wrote: > > On Aug 24, 2014, at 5:14 PM, Henry Gessau > wrote: > >> Ihar Hrachyshka wrote: >>> Now, maybe putting the module into requirements.txt is an >>> overkill (though I doubt it). In that case, we could be >>>

[openstack-dev] [Fuel] Doc team working with bugs

Hello Fuelers, On the previous meeting a topic was raised on how Fuel doc team should work with bugs, see [1] for details. We agreed to move the discussion into the mailing list. The thing is there are two members in the team at the moment (Meg and Irina) and they need to distribute work among th

Re: [openstack-dev] [nova] [gantt] Scheduler cleanup - what did we agree to

Hi Don, Adding [nova] in the subject too, because we could miss some people here. Le 08/09/2014 07:24, Dugger, Donald D a écrit : As I mentioned in a prior email I think that, although we’re in agreement on what needs to be done before splitting out the scheduler into the Gantt project, I b

Re: [openstack-dev] [Swift] (Non-)consistency of the Swift hash ring implementation

That's great to hear! I see now that Swift's implementation has some additional rebalancing logic that Ironic (and the code example from Gregory's blog) lacked. Cheers, Nejc On 09/08/2014 05:39 AM, John Dickinson wrote: To test Swift directly, I used the CLI tools that Swift provides for mana

Re: [openstack-dev] [neutron] python-neutronclient, launchpad, and milestones

- Original Message - > On Sat, Sep 6, 2014 at 9:08 PM, Kyle Mestery wrote: > > On Sat, Sep 6, 2014 at 8:43 AM, Matt Riedemann > > wrote: > >> > >> > >> On 8/29/2014 1:53 PM, Kyle Mestery wrote: > >>> > >>> On Fri, Aug 29, 2014 at 1:40 PM, Matt Riedemann > >>> wrote: > > > >>>

Re: [openstack-dev] doubling our core review bandwidth

On Mon, Sep 08, 2014 at 03:14:24PM +1200, Robert Collins wrote: > I hope the subject got your attention :). > > This might be a side effect of my having too many cosmic rays, but its > been percolating for a bit. > > tl;dr I think we should drop our 'needs 2x+2 to land' rule and instead > use 'ne

[openstack-dev] [Fuel] SSL in Fuel

Hi all, As next step for improving Fuel security we are introducing SSL for both Fuel [1] and OS API endpoints [2]. Both specs assume usage of self-signed certificates generated by Fuel. It also required to allow users to use their own certs to secure their deployments (two blueprints that touch t

Re: [openstack-dev] [Nova] List of granted FFEs

On 6 September 2014 15:32, Thierry Carrez wrote: > Michael Still wrote: >> I've built this handy dandy list of granted FFEs, because searching >> email to find out what is approved is horrible. It would be good if >> people with approved FFEs could check their thing is listed here: >> >> https

[openstack-dev] [rally] KeyError: 'admin'

Hi, rally developers! Now, I am trying to use Rally to devstack cluster on AWS VM (all-in-one). I'm following a blog post https://www.mirantis.com/blog/rally-openstack-tempest-testing-made-simpler/ . I successfully installed Devstack, Rally and Tempest. Now, I just ran Tempest by 'rally verify st

Re: [openstack-dev] [rally] KeyError: 'admin'

Hi Daisuke, seems like your issue is connected to the change in the deployment configuration file format for existing clouds we've merged recently. Please see the updated Wiki "How to" page

Re: [openstack-dev] [rally] KeyError: 'admin'

Daisuke, We have as well changes in our DB models. So running: $ rally-manage db recreate Will be as well required.. Best regards, Boris Pavlovic On Mon, Sep 8, 2014 at 3:24 PM, Mikhail Dubov wrote: > Hi Daisuke, > > seems like your issue is connected to the change in the deployment >

Re: [openstack-dev] [rally] KeyError: 'admin'

Hi Mikhail, Thanks for your quick reply. I have already added cloud by using json format. Just to be safe, I retried to create deployment by following "How to", but the same error is shown now. My existing.json is as follows. Is there anything wrong? { "type": "ExistingCloud", "au

[openstack-dev] [Glance][FFE] Refactoring Glance Logging

All, There is two changes still not landed from https://blueprints.launchpad.net/glance/+spec/refactoring-glance-logging https://review.openstack.org/116626 and https://review.openstack.org/#/c/117204/ Merge of the changes was delayed over J3 to avoid any potential merge conflicts. There was

[openstack-dev] about Distributed OpenStack Cluster

Hi all, Today I am searching for a solution to distribute OpenStack over several geographies/availabilitiy zones and we found one from Huawei in [1]. In short, it's a classical centralized solution like Eucalyptus cloud [2], whereby there is a central control for all clusters in a top down top

Re: [openstack-dev] [rally] KeyError: 'admin'

Hi Daisuke, have you executed as well * $ rally-manage db recreate* as Boris pointed out in the previous letter? Best regards, Mikhail Dubov Community Mirantis, Inc. E-Mail: [email protected] Skype: msdubov On Mon, Sep 8, 2014 at 3:46 PM, Daisuke Morita wrote: > > Hi Mikhail, > > Thanks

Re: [openstack-dev] [rally] KeyError: 'admin'

Thanks, Boris. I tried "rally-manage db recreate" before registering a deployment, but nothing changed at all in running Tempest... It is late in Japan, so I will try it tomorrow. Best regards, Daisuke On 2014/09/08 20:38, Boris Pavlovic wrote: Daisuke, We have as well changes in our DB

Re: [openstack-dev] about Distributed OpenStack Cluster

On 8 September 2014 14:00, Vo Hoang, Tri wrote: > > Today I am searching for a solution to distribute OpenStack over several > geographies/availabilitiy zones and we found one from Huawei in [1]. In > short, it’s a classical centralized solution like Eucalyptus cloud [2], > whereby there is a ce

Re: [openstack-dev] Rally scenario Issue

Hello Harshil, looks like it can be the limitations of your deployment or bug in my code. Could you please try to create several tenants, routers and networks in these tenants manually to verify that it is possible? I tested this patch set on my lab with Neutron GRE, probably we should add someti

Re: [openstack-dev] doubling our core review bandwidth

On 09/08/2014 05:17 AM, Steven Hardy wrote: > On Mon, Sep 08, 2014 at 03:14:24PM +1200, Robert Collins wrote: >> I hope the subject got your attention :). >> >> This might be a side effect of my having too many cosmic rays, but its >> been percolating for a bit. >> >> tl;dr I think we should drop o

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Sun, 7 Sep 2014, Monty Taylor wrote: 1. Caring about end user experience at all 2. Less features, more win 3. Deleting things Yes. I'll give away all of my list for any one of these. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent _

[openstack-dev] [Heat] convergence flow diagrams

Hi All, As per the heat mid cycle meetup whiteboard, we have created the flowchart and sequence diagram for the convergence . Can you please review these diagrams and provide your feedback? https://www.dropbox.com/sh/i8qbjtgfdxn4zx4/AAC6J-Nps8J12TzfuCut49ioa?dl=0 Thanks, Ishant __

Re: [openstack-dev] doubling our core review bandwidth

On 09/08/2014 08:52 AM, Russell Bryant wrote: > On 09/08/2014 05:17 AM, Steven Hardy wrote: >> On Mon, Sep 08, 2014 at 03:14:24PM +1200, Robert Collins wrote: >>> I hope the subject got your attention :). >>> >>> This might be a side effect of my having too many cosmic rays, but its >>> been percol

Re: [openstack-dev] doubling our core review bandwidth

On 09/08/2014 02:52 PM, Russell Bryant wrote: > On 09/08/2014 05:17 AM, Steven Hardy wrote: >> On Mon, Sep 08, 2014 at 03:14:24PM +1200, Robert Collins wrote: >>> I hope the subject got your attention :). >>> >>> This might be a side effect of my having too many cosmic rays, but its >>> been percol

[openstack-dev] [Cinder][Nova] Moving Brick out of Cinder

Hi All! I would to start moving Cinder Brick [1] to oslo as was described on Cinder mid-cycle meetup [2]. Unfortunately I missed meetup so I want be sure that nobody started it and we are on the same page. According to the Juno 3 release, there was not enough time to discuss [3] on the latest Cin

[openstack-dev] [neutron] Remdiner: Team meeting on Tuesday at 1400 UTC

Just a reminder since this is the first week we'll do the rotating meeting. Please add agenda items to the meeting here [1]. See you all tomorrow! Kyle [1] https://wiki.openstack.org/wiki/Network/Meetings ___ OpenStack-dev mailing list OpenStack-dev@l

Re: [openstack-dev] [Nova] List of granted FFEs

Thank you, Michael. Dan From: Michael Still Sent: Sunday, September 7, 2014 10:52 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova] List of granted FFEs Ahhh, I didn't realize Jay had added his name in

Re: [openstack-dev] [Ceilometer] Complex resource_metadata could fail to store in MongoDB

On Thu, Sep 4, 2014 at 1:16 PM, Nadya Privalova wrote: > IMHO it's ok and even very natural to expect "escaped" query from users. > e.g, we store the following structure > > {metadata: > { Zoo: >{Foo.Boo: ''value"}}} > Yep but such structure c

Re: [openstack-dev] [Fuel] Doc team working with bugs

On 09/08/2014 03:46 AM, Dmitry Mescheryakov wrote: Hello Fuelers, On the previous meeting a topic was raised on how Fuel doc team should work with bugs, see [1] for details. We agreed to move the discussion into the mailing list. The thing is there are two members in the team at the moment (Meg

Re: [openstack-dev] [neutron] non-deterministic gate failures due to unclosed eventlet Timeouts

John Schwarz wrote: > Long story short: for future reference, if you initialize an eventlet > Timeout, make sure you close it (either with a context manager or simply > timeout.close()), and be extra-careful when writing tests using > eventlet Timeouts, because these timeouts don't implicitly expir

Re: [openstack-dev] [cinder] new cinderclient release this week?

John Griffith wrote: > Yes, now that RC1 is tagged I'm planning to tag a new cinderclient > tomorrow. I'll be sure to send an announcement out as soon as it's up. You mean, now that juno-3 is tagged ;) RC1 is still a few weeks and a few dozens bugfixes away. -- Thierry Carrez (ttx) ___

[openstack-dev] oslo.config 1.4.0.0a4 released - juno rc1

The Oslo team is pleased to release version 1.4.0.0a4 of oslo.config, our first release candidate for oslo.config for juno. This release includes: $ git log --no-merges --oneline 1.4.0.0a3..1.4.0.0a4 6acc2dd Updated from global requirements a590c2a Log a fixed length string of asterisks for obfu

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

>> The last few days have been interesting as I watch FFEs come through. >> People post explaining their feature, its importance, and the risk >> associated with it. Three cores sign on for review. All of the ones >> I've looked at have received active review since being posted. Would >> it be bonk

[openstack-dev] oslo.i18n 0.3.0 released - juno rc1

The Oslo team is pleased to announce the release of version 0.3.0 of oslo.i18n, our first release candidate for oslo.i18n for juno. This release includes: $ git log --oneline --no-merges 0.2.0..0.3.0 08bee34 Imported Translations from Transifex aa251be Updated from global requirements 106387b Im

[openstack-dev] oslo.messaging 1.4.0.0a5 released - juno rc1

The Oslo team is pleased to announce the release of version 1.4.0.0a5 of oslo.messaging, our first release candidate for oslo.messaging for juno. This release includes: $ git log --oneline --no-merges 1.4.0.0a4..1.4.0.0a5 6ea3b12 Imported Translations from Transifex fbee941 An initial implementa

[openstack-dev] [python-novaclient] servers list

Hi guys, I'm working with 'servers.list' call in 'nova.novaclient' and I'm getting different server lists depending on whether the user issuing the call is and admin or not. It seems like only an admin user can filter the returned list while a non-admin gets a list of all the servers no matter

[openstack-dev] oslo.serialization 0.2.0 released - juno rc1

The Oslo team is pleased to release version 0.2.0 of oslo.serialization, our first release candidate for oslo.serialization for juno. This release includes: $ git log --no-merges --oneline 0.1.0..0.2.0 4d61c82 Check for namedtuple_as_object support before using it Please report issues to the NE

Re: [openstack-dev] [python-novaclient] servers list

On 09/08/2014 10:27 AM, Abbass MAROUNI wrote: Hi guys, I'm working with 'servers.list' call in 'nova.novaclient' and I'm getting different server lists depending on whether the user issuing the call is and admin or not. It seems like only an admin user can filter the returned list while a non-ad

[openstack-dev] oslo.utils 0.3.0 released - juno rc1

The Oslo team is pleased to release version 0.3.0 of oslo.utils, our first release candidate for oslo.utils for juno. This release includes: $ git log --oneline --no-merges 0.2.0..0.3.0 6a123fc Imported Translations from Transifex 271f1b2 Remove unused dependency on oslo.config e81ecac Updated f

Re: [openstack-dev] [NFV] NFV Meetings

- Original Message - > From: "ITAI MENDELSOHN (ITAI)" > To: "OpenStack Development Mailing List (not for usage questions)" > > > Hi, > > Hope you are doing good. > Did we have a meeting last week? > I was under the impression it¹s was scheduled to Thursday (as in the wiki) > but found

Re: [openstack-dev] [nova][neutron] default allow security group

On 09/05/2014 11:27 AM, Monty Taylor wrote: > Hi! > > I've decided that as I have problems with OpenStack while using it in the > service of Infra, I'm going to just start spamming the list. > > Please make something like this: > > neutron security-group-create default --allow-every-damn-thing

[openstack-dev] cliff 1.7.0 released

The Oslo team is pleased to release version 1.7.0 of cliff. This release includes: $ git log --oneline --no-merges 1.6.1..1.7.0 42675b2 Add release notes for 1.7.0 86fe20f Fix stable integration tests bf0c611 Updated from global requirements ac1347c Clean up default tox environment list db4eef5 D

[openstack-dev] stevedore 1.0.0.0a2 released -- juno rc1

The Oslo team is pleased to release version 1.0.0.0a2 of stevedore, our first release candidate for stevedore for the OpenStack Juno cycle. This release includes: $ git log --oneline --no-merges 1.0.0.0a1..1.0.0.0a2 860bd8f Build universal wheels Please report issues to the stevedore bug tracke

Re: [openstack-dev] doubling our core review bandwidth

Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400: > > On 09/08/2014 05:17 AM, Steven Hardy wrote: > >> I think this may be a sensible move, but only if it's used primarily to > >> land the less complex/risky patches more quickly. > > 2 +2 has been part of OpenStack culture for a long time,

Re: [openstack-dev] [Heat] Defining what is a SupportStatus version

On Fri, Sep 5, 2014 at 5:27 AM, Steven Hardy wrote: > On Fri, Sep 05, 2014 at 03:56:34PM +1000, Angus Salkeld wrote: > >On Fri, Sep 5, 2014 at 3:29 PM, Gauvain Pocentek > > wrote: > > > > Hi, > > > > A bit of background: I'm working on the publication of the HOT > resources > >

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Sep 7, 2014, at 9:27 PM, Anita Kuno wrote: > On 09/07/2014 09:12 PM, Angus Salkeld wrote: >> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making >> users happy. > I don't understand why you would encourage writers of blog posts you > disagree with by sending them traffic.

Re: [openstack-dev] doubling our core review bandwidth

On 09/08/2014 11:07 AM, Alexis Lee wrote: > Sean Dague said on Mon, Sep 08, 2014 at 09:22:56AM -0400: >>> On 09/08/2014 05:17 AM, Steven Hardy wrote: I think this may be a sensible move, but only if it's used primarily to land the less complex/risky patches more quickly. >> >> 2 +2 has be

Re: [openstack-dev] [neutron] non-deterministic gate failures due to unclosed eventlet Timeouts

On Sep 7, 2014, at 9:39 AM, John Schwarz wrote: > Hi, > > Long story short: for future reference, if you initialize an eventlet > Timeout, make sure you close it (either with a context manager or simply > timeout.close()), and be extra-careful when writing tests using > eventlet Timeouts, becau

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/08/2014 11:12 AM, Mike Bayer wrote: > > On Sep 7, 2014, at 9:27 PM, Anita Kuno wrote: > >> On 09/07/2014 09:12 PM, Angus Salkeld wrote: >>> Lets prevent blogs like this: http://jimhconsulting.com/?p=673 by making >>> users happy. >> I don't understand why you would encourage writers of blo

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Sep 7, 2014, at 8:14 PM, Monty Taylor wrote: > > > 2. Less features, more win > > In a perfect world, I'd argue that we should merge exactly zero new features > in all of kilo, and instead focus on making the ones we have work well. Some > of making the ones we have work well may wind up

Re: [openstack-dev] [Fuel] SSL in Fuel

blueprints for non-self-signed certs/PKI for starters. *Adam Lawson* *CEO, Principal Architect* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Mon, Sep 8, 2014 at 2

Re: [openstack-dev] [Heat] Should docker plugin remove containers on delete?

On 01/09/14 19:18, Steve Baker wrote: On 02/09/14 05:58, Lars Kellogg-Stedman wrote: Hello all, I recently submitted this change: https://review.openstack.org/#/c/118190/ This causes the Docker plugin to *remove* containers on delete, rather than simply *stopping* them. When creating name

Re: [openstack-dev] Kilo Cycle Goals Exercise

On Sep 8, 2014, at 11:30 AM, Anita Kuno wrote: > Wow, we are really taking liberties with my question today. > > What part of any of my actions current or previous have led you to > believe that I want to now or ever have silenced anyone? I am curious > what led you to believe that silencing us

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

On 09/05/2014 06:10 AM, Sylvain Bauza wrote: Le 05/09/2014 12:48, Sean Dague a écrit : On 09/05/2014 03:02 AM, Sylvain Bauza wrote: Le 05/09/2014 01:22, Michael Still a écrit : On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange wrote: [Heavy snipping because of length] The radical (?) sol

Re: [openstack-dev] doubling our core review bandwidth

> tl;dr I think we should drop our 'needs 2x+2 to land' rule and instead > use 'needs 1x+2'. We can ease up a large chunk of pressure on our > review bottleneck, with the only significant negative being that core > reviewers may see less of the code going into the system - but they > can always rea

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/08/2014 12:00 PM, Mike Bayer wrote: > > On Sep 8, 2014, at 11:30 AM, Anita Kuno wrote: > >> Wow, we are really taking liberties with my question today. >> >> What part of any of my actions current or previous have led you to >> believe that I want to now or ever have silenced anyone? I am

Re: [openstack-dev] [nova] Averting the Nova crisis by splitting out virt drivers

Le 08/09/2014 18:06, Steven Dake a écrit : On 09/05/2014 06:10 AM, Sylvain Bauza wrote: Le 05/09/2014 12:48, Sean Dague a écrit : On 09/05/2014 03:02 AM, Sylvain Bauza wrote: Le 05/09/2014 01:22, Michael Still a écrit : On Thu, Sep 4, 2014 at 5:24 AM, Daniel P. Berrange wrote: [Heavy snip

[openstack-dev] [Mistral] Team meeting minutes/log - 08/09/2014

Thanks for joining us today at our team meeting! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-08-16.00.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2014/mistral.2014-09-08-16.00.log.html Agenda/Meeting archive: https://wiki.openstack.

[openstack-dev] [Fuel] Working on 6.0 and new releases in general

Hello Fuelers, Right now we have the following policy in place: the branches for a release are opened only after its 'parent' release have reached hard code freeze (HCF). Say, 5.1 release is parent releases for 5.1.1 and 6.0. And that is the problem: if parent release is delayed, we can't properl

[openstack-dev] [qa] Reminder: Tempest Bug Day: Tuesday September 9 (tomorrow)

It's been a while since we had a bug day. We now have 121 (now 124) NEW bugs: https://bugs.launchpad.net/tempest/+bugs?field.searchtext=&field.status%3Alist=NEW&orderby=-importance The first order of business is to triage these bugs. This is a large enough number that I hesitate to mention a

Re: [openstack-dev] [Neutron] - reading router external IPs

I think there could be some discussion about the validity of this as a bug report vs a feature enhancement. Personally, I think I could be talked in to accepting a small change to address this "bug" but I won't try to speak for everyone. This bug report [1] -- linked by devvesa to the bug report

[openstack-dev] [Infra] Meeting Tuesday September 9th at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is hosting our weekly meeting on Tuesday September 9th, 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

[openstack-dev] [QA] Summit Session Brainstorming

Hi Everyone, Based on all of the discussions that we've been having about summit planning the last few weeks I figured that it would be a good idea to also start brainstorming ideas for summit sessions a bit earlier this time. I've put up an etherpad here to start the discussion: https://etherp

Re: [openstack-dev] Kilo Cycle Goals Exercise

Monty, +1!! I fully agree!! How can I help :-)? Can we dedicate some design summit sessions to this topic? Ideally, having some stakeholder driven sessions where we can hear about the user experiences issues causing the most pain would be a good start to get this to become a focus area.

Re: [openstack-dev] doubling our core review bandwidth

On 07/09/14 23:43, Morgan Fainberg wrote: ## avoiding collaboration between bad actors > >The two core requirement means that it takes three people (proposer + >2 core) to collaborate on landing something inappropriate (whether its >half baked, a misfeature, whatever). Thats only 50% harder than

Re: [openstack-dev] Kilo Cycle Goals Exercise

The End User working group is being described at https://wiki.openstack.org/wiki/End_User_Working_Group. Chris Kemp is establishing the structure. This page covers how to get involved... Tim From: Brad Topol [mailto:[email protected]] Sent: 08 September 2014 19:50 To: OpenStack Development Ma

Re: [openstack-dev] [Neutron] - reading router external IPs

IIUC, the required policy change is to allow a tenant to list ports that don't belong to you. I don't think the policy.json is powerful enough to allow tenants to list their external ports but no other ports they don't own. On Sep 8, 2014 10:30 AM, "Carl Baldwin" wrote: > I think there could be s

Re: [openstack-dev] Kilo Cycle Goals Exercise

Amen to this! I've always felt bad that before yahoo tries to include a new feature in its openstack cloud/s we have to figure out how much the feature is a land-mine, how much of it works, how much of it doesn't and so-on. That type of investigation imho shouldn't really be needed and the fact

[openstack-dev] [oslo] Anticipated Final Release Versions for Juno

I spent some time today looking over our current set of libraries trying to anticipate which will be ready for 1.0 (or later) and which are still considered pre-release. I came up with this set of anticipated version numbers for our final juno releases. Please let me know if you see any surprise

Re: [openstack-dev] [oslo] Anticipated Final Release Versions for Juno

LGTM Doug. for oslo.vmware - we need a fresh rev for use by Nova to fix the following bug: https://bugs.launchpad.net/nova/+bug/1341954 thanks, dims On Mon, Sep 8, 2014 at 2:32 PM, Doug Hellmann wrote: > I spent some time today looking over our current set of libraries trying to > anticipate wh

[openstack-dev] Error creating instances in DevStack

Hi, I am trying to setup my own OpenStack cloud for development. I installed DevStack on a VM and the installation is fine. I am able to log in via Horizon. I followed these steps to create an instance via Horizon. http://isurues.wordpress.com/tag/devstack/. However, when I launch an instance, I g

Re: [openstack-dev] Error creating instances in DevStack

On Mon, Sep 8, 2014 at 1:40 PM, Sharan Kumar M wrote: > I am trying to setup my own OpenStack cloud for development. I installed > DevStack on a VM and the installation is fine. I am able to log in via > ... > I checked if the libvirt_type=qemu in nova.conf. Also the package > nova-compute-qem

Re: [openstack-dev] Error creating instances in DevStack

Check your scheduler logs you should be able to figure out whats happening. If not clear then turn on your logs from info mode to debug in nova.conf. -Hemant On Tue, Sep 9, 2014 at 12:10 AM, Sharan Kumar M wrote: > Hi, > > I am trying to setup my own OpenStack cloud for development. I installe

[openstack-dev] [cinder][FFE] request for exceptions in xiv_ds8k driver

Hi, Please consider the following code changes as Feature Freeze Exceptions. The first code change is needed to support the latest XIV release (version 11.5.0) and is very important for us, and the second code change is simply support for backups. Add domain support for XIV with multitenancy

[openstack-dev] Standard virtualenv for docs building

Hi all, I just wanted to get some feedback on a change that I think will make the docs building process more understood, Currently there is a script @ https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/slave_scripts/run-docs.sh (this is the github mirror fyi)

Re: [openstack-dev] Announcing Gertty 1.0.0: A console interface to Gerrit

I just released 1.0.1 with some bug fixes for issues found by early adopters. Thanks! -Jim ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] China blocking access to OpenStack git review push

Am I dreaming, or is the Chinese government is trying to push for the cloud, they said. However, today, bad surprise: # nmap -p 29418 23.253.232.87 Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST Nmap scan report for review.openstack.org (23.253.232.87) Host is up (0.21s latency).

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 09/03/2014 12:16 PM, Doug Hellmann wrote: On Sep 3, 2014, at 11:37 AM, Joe Gordon mailto:[email protected]>> wrote: As you all know, there has recently been several very active discussions around how to improve assorted aspects of our development process. One idea that was brought up is

Re: [openstack-dev] China blocking access to OpenStack git review push

On Mon, Sep 8, 2014, at 12:20 PM, Thomas Goirand wrote: > Am I dreaming, or is the Chinese government is trying to push for the > cloud, they said. However, today, bad surprise: > > # nmap -p 29418 23.253.232.87 > > Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST > Nmap scan report

Re: [openstack-dev] [cinder][FFE] request for exceptions in xiv_ds8k driver

Alon, Thanks, I have added your request to the etherpad https://etherpad.openstack.org/p/juno-cinder-approved-ffes and it will undergo review. Thanks, Jay On Mon, 2014-09-08 at 21:55 +0300, Alon Marx wrote: > Hi, > > Please consider the following code changes as Feature Freeze > Exceptions.

Re: [openstack-dev] [Fuel] Doc team working with bugs

On Mon, Sep 8, 2014 at 9:04 AM, Jay Pipes wrote: > On 09/08/2014 03:46 AM, Dmitry Mescheryakov wrote: > >> Hello Fuelers, >> >> On the previous meeting a topic was raised on how Fuel doc team should >> work with bugs, see [1] for details. We agreed to move the discussion >> into the mailing list.

Re: [openstack-dev] Standard virtualenv for docs building

On 09/08/2014 11:59 AM, Joshua Harlow wrote: Hi all, I just wanted to get some feedback on a change that I think will make the docs building process more understood, Currently there is a script @ https://github.com/openstack-infra/config/blob/master/modules/openstack_project/files/slave_scrip

Re: [openstack-dev] Kilo Cycle Goals Exercise

Thanks for starting this, Joe. I think that we need to address the operator and user experience by improving the consistency and stability of OpenStack overall. Here are five ways of doing that: 1) Improve log correlation and utility If we're going to improve the stability of OpenStack, we have

Re: [openstack-dev] [neutron] [nova] non-deterministic gate failures due to unclosed eventlet Timeouts

On 09/07/2014 10:43 AM, Matt Riedemann wrote: On 9/7/2014 8:39 AM, John Schwarz wrote: Hi, Long story short: for future reference, if you initialize an eventlet Timeout, make sure you close it (either with a context manager or simply timeout.close()), and be extra-careful when writing tests usi

Re: [openstack-dev] China blocking access to OpenStack git review push

On 9/8/2014 2:20 PM, Thomas Goirand wrote: Am I dreaming, or is the Chinese government is trying to push for the cloud, they said. However, today, bad surprise: # nmap -p 29418 23.253.232.87 Starting Nmap 6.00 ( http://nmap.org ) at 2014-09-09 03:10 CST Nmap scan report for review.openstack.o

Re: [openstack-dev] [rally] KeyError: 'admin'

Daisuke, This patch https://review.openstack.org/#/c/116766/ introduced this bug: https://bugs.launchpad.net/rally/+bug/1366824 That was fixed by this commit: https://review.openstack.org/#/c/119790/ So update your rally and try one more time. Everything should work now. Best regards, Boris Pa

Re: [openstack-dev] Kilo Cycle Goals Exercise

On 2014-09-07 8:14 PM, Monty Taylor wrote: If I were king ... 1. Caring about end user experience at all If I don't do anything at all next cycle, I will see the above fixed. Because it's embarrassing. Seriously. Try to use OpenStack from python some time. I dare you. > > [...] Between 2 an

[openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

Hi All, We have recently started seeing assorted memory issues in the gate including the oom-killer [0] and libvirt throwing memory errors [1]. Luckily we run ps and dstat on every devstack run so we have some insight into why we are running out of memory. Based on the output from job taken at ran

[openstack-dev] [tripleo] Puppet elements support

Hi TripleO community, I would be really interested by helping to bring Puppet elements support in TripleO. So far I've seen this work: https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat which is a very good bootstrap but really outdated. After some discussion with Greg Haynes o

Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

On 09/09/2014 08:24 AM, Joe Gordon wrote: 1) Should we explicitly set the number of workers that services use in devstack? Why have so many workers in a small all-in-one environment? What is the right balance here? There is a review out for that [1]. Devstack has a switch for everything, and t

Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

Hi All - Joe had me do some quick memory profiling on nova, just an FYI if anyone wants to play with this technique, I place a little bit of memory profiling code using Guppy into nova/api/__init__.py, or anywhere in your favorite app that will definitely get imported when the thing first runs

Re: [openstack-dev] [Glance][FFE] Refactoring Glance Logging

In principle I don't think these changes need FFE, because they aren't really features so much as fixes for better logging and internationalization. On Mon, Sep 8, 2014 at 4:50 AM, Kuvaja, Erno wrote: > All, > > > > There is two changes still not landed from > https://blueprints.launchpad.net/

Re: [openstack-dev] [Heat] convergence flow diagrams

On Mon, Sep 8, 2014 at 11:22 PM, Tyagi, Ishant wrote: > Hi All, > > > > As per the heat mid cycle meetup whiteboard, we have created the > flowchart and sequence diagram for the convergence . Can you please review > these diagrams and provide your feedback? > > > > https://www.dropbox.com/sh/i8q

Re: [openstack-dev] how to provide tests environments for python things that require C extensions

Sean Dague writes: > The crux of the issue is that zookeeper python modules are C extensions. > So you have to either install from packages (which we don't do in unit > tests) or install from pip, which means forcing zookeeper dev packages > locally. Realistically this is the same issue we end up

Re: [openstack-dev] how to provide tests environments for python things that require C extensions

On 09/05/2014 07:21 AM, Monty Taylor wrote: On 09/05/2014 06:32 AM, Sean Dague wrote: While reviewing this zookeeper service group fix in Nova - https://review.openstack.org/#/c/102639/ it was exposed that the zookeeper tests aren't running in infra. The crux of the issue is that zookeeper pyth

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

On 09/05/2014 07:07 PM, James Bottomley wrote: > Actually, I don't think this analysis is accurate. Some people are > simply interested in small aspects of a project. It's the "scratch your > own itch" part of open source. The thing which makes itch scratchers > not lone wolfs is the desire to g

Re: [openstack-dev] [tripleo] Puppet elements support

On 09/08/2014 04:11 PM, Emilien Macchi wrote: Hi TripleO community, I would be really interested by helping to bring Puppet elements support in TripleO. So far I've seen this work: https://github.com/agroup/tripleo-puppet-elements/tree/puppet_dev_heat which is a very good bootstrap but really ou

Re: [openstack-dev] [tripleo] Puppet elements support

I would be happy to contribute to and help review this project. On Sep 8, 2014 4:14 PM, "Emilien Macchi" wrote: > Hi TripleO community, > > I would be really interested by helping to bring Puppet elements support > in TripleO. > So far I've seen this work: > https://github.com/agroup/tripleo-pupp

Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

Excerpts from Joe Gordon's message of 2014-09-08 15:24:29 -0700: > Hi All, > > We have recently started seeing assorted memory issues in the gate > including the oom-killer [0] and libvirt throwing memory errors [1]. > Luckily we run ps and dstat on every devstack run so we have some insight > int

Re: [openstack-dev] [nova][neutron][cinder] Averting the Nova crisis by splitting out virt drivers

A somewhat self-serving way to start to solve this is to make training and mentoring as the first steps to getting involved with contributions. We would continue to gradually give more responsibilities as the experience and skills increase. We do this last part already, but are missing the suppo

  1   2   >