Re: [openstack-dev] Supporting Javascript clients calling OpenStack APIs

Diego Parrilla Santamaría writes: > May be it's a bit too late, but in mid 2012 the FIWARE team developed a > horizon clone 100% in Javascript. https://github.com/ging/horizon-js Nice! I poked around a little in the repo and found no mention of Swift? > [...] Portal has evolved and now it's mor

Re: [openstack-dev] [Nova] Automatic evacuate

> -Original Message- > From: Russell Bryant [mailto:[email protected]] > Sent: Thursday, October 16, 2014 5:04 AM > To: [email protected] > Subject: Re: [openstack-dev] [Nova] Automatic evacuate > > On 10/15/2014 05:07 PM, Florian Haas wrote: > > On Wed, Oct 15, 2014 at

Re: [openstack-dev] [Nova] Automatic evacuate

Le 16/10/2014 05:04, Russell Bryant a écrit : On 10/15/2014 05:07 PM, Florian Haas wrote: On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant wrote: Am I making sense? Yep, the downside is just that you need to provide a new set of flavors for "ha" vs "non-ha". A benefit though is that it's a

Re: [openstack-dev] [Nova] Automatic evacuate

(5) Let monitoring and orchestration services deal with these use cases and have Nova simply provide the primitive API calls that it already does (i.e. host evacuate). >>> >>> That would arguably lead to an incredible amount of wheel reinvention >>> for node failure detecti

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 5:04 AM, Russell Bryant wrote: > On 10/15/2014 05:07 PM, Florian Haas wrote: >> On Wed, Oct 15, 2014 at 10:03 PM, Russell Bryant wrote: Am I making sense? >>> >>> Yep, the downside is just that you need to provide a new set of flavors >>> for "ha" vs "non-ha". A bene

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 9:25 AM, Jastrzebski, Michal wrote: > In my opinion flavor defining is a bit hacky. Sure, it will provide us > functionality fairly quickly, but also will strip us from flexibility Heat > would give. Healing can be done in several ways, simple destroy -> create > (basic con

Re: [openstack-dev] My notes and experiences about OSv on OpenStack

Hey Glauber that would be great! See you in Paris then :) On Thu, Oct 16, 2014 at 4:32 PM, Glauber Costa wrote: > Hello guys > > Just to let you know, I won't be in the Summit because I am too busy due > to the fact I am relocating to a foreign country. > > However, that country happens to be Fr

Re: [openstack-dev] [Nova] Automatic evacuate

> >> This still doesn't do away with the requirement to reliably detect > >> node failure, and to fence misbehaving nodes. Detecting that a node > >> has failed, and fencing it if unsure, is a prerequisite for any > >> recovery action. So you need Corosync/Pacemaker anyway. > > > > Obviously, yes.

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 11:01 AM, Thomas Herve wrote: > >> >> This still doesn't do away with the requirement to reliably detect >> >> node failure, and to fence misbehaving nodes. Detecting that a node >> >> has failed, and fencing it if unsure, is a prerequisite for any >> >> recovery action. So

Re: [openstack-dev] [Neutron] [ml2] How ML2 reflects on the topology?

Hi, if you use a VLAN type driver, TOR switches should be configured in trunk mode to allow VLAN specified in vlan_type section of ml2_conf.ini. vlan id range is defined in this section. Any tenant network will use an id from this range, and it is totally independent from tenant id. Some mechanism

Re: [openstack-dev] [api] API recommendation

In an analysis we recently did for managing lifecycle of neutron resources, it also emerged that task (or operation) API are a very useful resource. Indeed several neutron resources introduced the (in)famous PENDING_XXX operational statuses to note the fact that an operation is in progress and its

Re: [openstack-dev] [api] API recommendation

2014-10-16 17:57 GMT+08:00 Salvatore Orlando : > In an analysis we recently did for managing lifecycle of neutron > resources, it also emerged that task (or operation) API are a very useful > resource. > Indeed several neutron resources introduced the (in)famous PENDING_XXX > operational statuses

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 04:29 AM, Florian Haas wrote: > (5) Let monitoring and orchestration services deal with these use > cases and > have Nova simply provide the primitive API calls that it already does > (i.e. > host evacuate). That would arguably lead to an incredible amoun

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 05:01 AM, Thomas Herve wrote: > This still doesn't do away with the requirement to reliably detect node failure, and to fence misbehaving nodes. Detecting that a node has failed, and fencing it if unsure, is a prerequisite for any recovery action. So you need Coro

[openstack-dev] [QA] Proposal: A launchpad bug description template

TL;DR: A proposal for a template for launchpad bug entries which asks for the minimal needed data to work on a bug. Hi, As a new guy in OpenStack I find myself often in the situation that I'm not able to work on a bug because I don't understand the problem itself. If I don't understand t

Re: [openstack-dev] [api] API recommendation

On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando wrote: > From an API guideline viewpoint, I understand that > https://review.openstack.org/#/c/86938/ proposes the introduction of a > rather simple endpoint to query active tasks and filter them by resource > uuid or state, for example. > That

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant wrote: > On 10/16/2014 04:29 AM, Florian Haas wrote: >> (5) Let monitoring and orchestration services deal with these use >> cases and >> have Nova simply provide the primitive API calls that it already does >> (i.e. >> host evacu

Re: [openstack-dev] Travels tips for the Paris summit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2014 03:25 AM, Thierry Carrez wrote: >>> What I can suggest is when looking at the menu (this is mandatory to put >>> >> it outside of the restaurant) and check for the word 'Végétarien'. > It's also always risky to ask for a vegetarian plate

[openstack-dev] [ceilometer] scheduling Kilo summit topics

Folks, Just a quick reminder that we'll be considering the summit design sessions proposals[1] at the weekly meeting today at 1500UTC. We'll start the process of collaborative scheduling of topics with each session proposer giving a short pitch for inclusion. We've got 15 proposals already, con

Re: [openstack-dev] Travels tips for the Paris summit

Le 16/10/2014 15:18, Ed Leafe a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/15/2014 03:25 AM, Thierry Carrez wrote: What I can suggest is when looking at the menu (this is mandatory to put it outside of the restaurant) and check for the word 'Végétarien'. It's also always ris

Re: [openstack-dev] [QA] Proposal: A launchpad bug description template

Hi Markus, Thank you for bringing up this. On Thu, Oct 16, 2014 at 9:13 PM, Markus Zoeller wrote: > TL;DR: A proposal for a template for launchpad bug entries which asks >for the minimal needed data to work on a bug. > > > Hi, > > As a new guy in OpenStack I find myself often in the situ

[openstack-dev] [sahara] canceled weekly meeting October, 16

Hi sahara folks, I'm cancelling weekly irc meeting this week due to the release. Thanks. -- Sincerely yours, Sergey Lukjanov Sahara Technical Lead (OpenStack Data Processing) Principal Software Engineer Mirantis Inc. ___ OpenStack-dev mailing list Ope

Re: [openstack-dev] [Openstack] [QA] How to attach multiple NICs to an instance VM?

> > Is this the correct way to attach multiple NICs to an instance? > > Thanks, > Danny > Hi, run a dhcp client on second instance, it should get added IP. if you want to add port to existing instance then create port in neutron: neutron port-create --fixed-ip ip_address=1.2.3.4 vm_network_n

Re: [openstack-dev] [Nova] Automatic evacuate

- Original Message - > From: "Florian Haas" > To: "OpenStack Development Mailing List (not for usage questions)" > > > On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant wrote: > > On 10/16/2014 04:29 AM, Florian Haas wrote: > >> (5) Let monitoring and orchestration services deal wi

[openstack-dev] [OpenStack] [Barbican] Cinder and Barbican

Dear all, is Cinder capable today to use Barbican for encryption? If yes, can you attach some useful doc? Thank you, Giuseppe ___ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-d

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 4:31 PM, Steve Gordon wrote: >> Running compute nodes as baremetal extensions of a different >> Corosync/Pacemaker cluster (presumably the one that manages the other >> Nova services) would potentially be an option, although vendors would >> need to buy into this. Ubuntu,

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 09:00 AM, Florian Haas wrote: > On Thu, Oct 16, 2014 at 1:59 PM, Russell Bryant wrote: >> On 10/16/2014 04:29 AM, Florian Haas wrote: >>> (5) Let monitoring and orchestration services deal with these use >>> cases and >>> have Nova simply provide the primitive API calls t

Re: [openstack-dev] [Neutron][DVR] Openstack Juno: how to configure dvr in Network-Node and Compute-Node?

Have you seen the “how-to” wiki page? https://wiki.openstack.org/wiki/Neutron/DVR/HowTo Yours, Michael Smith Hewlett-Packard Company HP Networking R&D 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747 PC Phone: 916 540-1884 Ph: 916 785-0918 Fax: 916 785-1199 From: zhang xiaobin [mailto:14050...@cn

Re: [openstack-dev] Travels tips for the Paris summit

On Thu, Oct 16 2014, Sylvain Bauza wrote: > Sure thing "Est-ce que ce plat contient de la viande ?" (ε-s kə sə pla > kɔ̃tjε̃ də > la vjɑ̃d ) Be careful because that a lot of places would answer "no" to that while it might be possible that the dish has things like fish in it… Many people, even in

[openstack-dev] [Neutron] BGPVPN implementation discussions

Hi all, as discussed during today's l3-meeting, we keep on working on BGPVPN service plugin implementation [1]. MPLS encapsulation is now supported in OVS [2], so we would like to summit a design to leverage OVS capabilities. A first design proposal, based on l3agent, can be found here : https://

Re: [openstack-dev] Travels tips for the Paris summit

On 10/16/2014 12:49 PM, Julien Danjou wrote: > On Thu, Oct 16 2014, Sylvain Bauza wrote: > >> Sure thing "Est-ce que ce plat contient de la viande ?" (ε-s kə >> sə pla kɔ̃tjε̃ də la vjɑ̃d ) > > Be careful because that a lot of places would answer "no" to that > while it might be possible that the

Re: [openstack-dev] [Nova] Automatic evacuate

Be forewarned; here's my two cents before I've had my morning coffee. It would seem to me that if we were seeking some level of resiliency against host failures (if a host fails, evacuate the instances that were hosted on it to a host that isn't broken), it would seem that host HA is a good approa

Re: [openstack-dev] [QA] Proposal: A launchpad bug description template

Masayuki Igawa wrote on 10/16/2014 03:41:24 PM: > From: Masayuki Igawa > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 10/16/2014 03:44 PM > Subject: Re: [openstack-dev] [QA] Proposal: A launchpad bug > description template > > Hi Markus, > > Thank you for bri

[openstack-dev] [Ironic][Ceilometer] Proposed Change to Sensor meter naming in Ceilometer

All, I would like to get some feedback on a proposal to change to the current sensor naming implemented in ironic and ceilometer. I would like to provide vendor specific sensors within the current structure for IPMI sensors in ironic and ceilometer, but I have found that the current implem

Re: [openstack-dev] [UX] [Heat] [Mistral] [Horizon] Merlin project PoC update: shift from HOT builder to Mistral Workbook builder

Drago, great news indeed! In the meantime I've started integrating Merlin PoC with the MIstral Workbook builder into Horizon. In case you follow the instructions at https://github.com/stackforge/merlin/blob/master/README.md you'll get working Project->Orchestration->Mistral panel with the Workbook

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 04:29 AM, Florian Haas wrote: (5) Let monitoring and orchestration services deal with these use cases and have Nova simply provide the primitive API calls that it already does (i.e. host evacuate). That would arguably lead to an incredible amount of wheel reinvention for node fail

Re: [openstack-dev] Travels tips for the Paris summit

On Oct 16, 2014, at 10:02 AM, Anita Kuno mailto:[email protected]>> wrote: Heh, yeah didn't expect to take over the thread on this, sorry about that. Perhaps we should form a group, vegetarians in Paris? I know myself and at least one other Summit attendee who has similarly annoying dietary

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 01:03 PM, Adam Lawson wrote: > Be forewarned; here's my two cents before I've had my morning coffee. > > It would seem to me that if we were seeking some level of resiliency > against host failures (if a host fails, evacuate the instances that were > hosted on it to a host that isn'

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 7:03 PM, Adam Lawson wrote: > > Be forewarned; here's my two cents before I've had my morning coffee. > > It would seem to me that if we were seeking some level of resiliency against > host failures (if a host fails, evacuate the instances that were hosted on it > to a ho

Re: [openstack-dev] Travels tips for the Paris summit

You can always try: http://www.timeout.com/paris/en/food-and-drink/vegetarian-restaurants-in-pa ris. On 10/16/14, 8:02 PM, "Anita Kuno" wrote: >On 10/16/2014 12:49 PM, Julien Danjou wrote: >> On Thu, Oct 16 2014, Sylvain Bauza wrote: >> >>> Sure thing "Est-ce que ce plat contient de la viande

Re: [openstack-dev] [Ironic][Ceilometer] Proposed Change to Sensor meter naming in Ceilometer

On Thu, Oct 16 2014, Jim Mankovich wrote: > This structure would provide the ability for a consumer to do a ceilometer > resource list using the Ironic Node ID as the Resource ID to get all the > sensors > in a given platform. The consumer would then then iterate over each of the > sensors to g

[openstack-dev] [Keystone] external AuthN Identity Backend

Hi, Currently we have two ways of doing Identity Auth backends, these are sql and ldap. The SQL backend is the default and is for situations where Keyston is the canonical Identity provider with username / password being directly compared to the Keystone database. LDAP is the current option if K

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

I think it depends on what you mean by 'external identity provider' - I assume it's capable of speaking some sort of federation protocol. So I'd rather explore adding more support for additional federation protocols/standards, rather than making our own third backend. Steve Dave Walker wrote on

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 7:48 PM, Jay Pipes wrote: >> While one of us (Jay or me) speaking for the other and saying we agree >> is a distributed consensus problem that dwarfs the complexity of >> Paxos > > > You've always had a way with words, Florian :) I knew you'd like that one. :) >>, *I* for

[openstack-dev] [barbican] Barbican Juno Release

Hi All, The Barbican team is proud to announce the final release of the Barbican Key Management Service for Juno: https://launchpad.net/barbican/juno/2014.2 This release includes 9 Blueprints and 47 bug fixes. Check the link above for the full details. Many thanks to all the contributors who m

Re: [openstack-dev] [Nova] Automatic evacuate

Okay the coffee kicked in. I can see how my comment could be interpreted that way so let's take a step backward so I can explain my perspective here. Amazon was the first to implement a commercial-grade cloud IaaS, Openstack was developed as an alternative. If we avoided wheel re-invention as a r

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

Hi Steve, Thanks for your response. I am talking generally about the external auth support. One use case is Kerberos, but for the sake of argument this could quite easily be Apache Basic auth. The point is, we have current support for entrusting AuthN outside of Keystone. What I was trying to

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

Dave when federation is used, the user's group is stored in a mapping rule. So we do have a mechanism for storing group memberships without using LDAP or creating an entry for the user in the SQL backend. (The only time this is kinda not true is if we have a specific rule for each federated user,

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

On Thu, Oct 16, 2014 at 2:54 PM, Dave Walker wrote: > Hi Steve, > > Thanks for your response. I am talking generally about the external > auth support. One use case is Kerberos, but for the sake of argument > this could quite easily be Apache Basic auth. The point is, we have > current support

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

On 16 October 2014 20:07, David Stanek wrote: > I may be missing something, but can you use the external auth method with > the LDAP backend? > No, as the purpose of the LDAP backend is to validate user/pass combination are valid. With the external auth plugin, these are not provided to keyston

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

Hi, I think I considered the Federated plugin as a mismatch as it dealt with 'remote' auth rather than 'external' auth. I thought it was for purely handling SSO / SAML2, and not being subordinate to auth with the webserver. I'll dig into the federation plugin more, thanks. -- Kind Regards, Dave

Re: [openstack-dev] [Nova] Automatic evacuate

On 10/16/2014 02:40 PM, Adam Lawson wrote: > Question: is host HA not achievable using the programs we have in place > now (with modification of course)? If not, I'm still a champion to see > it done within our four walls. Yes, it is achievable (without modification, even). That was the primary p

Re: [openstack-dev] [OpenStack] [Barbican] [Cinder] Cinder and Barbican

Hi Giuseppe, Someone from the Cinder team can correct me if I’m wrong, but I don’t think that Cinder has done any integration with Barbican yet. -Douglas Douglas Mendizábal IRC: redrobot PGP Key: 245C 7B6F 70E9 D8F3 F5D5 0CC9 AD14 1F30 2D58 923C From: Giuseppe Galeota Re

Re: [openstack-dev] [Nova] Automatic evacuate

On Thu, Oct 16, 2014 at 9:40 PM, Russell Bryant wrote: > On 10/16/2014 02:40 PM, Adam Lawson wrote: >> Question: is host HA not achievable using the programs we have in place >> now (with modification of course)? If not, I'm still a champion to see >> it done within our four walls. > > Yes, it is

[openstack-dev] [TripleO] Summit scheduling - using our time together wisely.

The format has changed slightly this summit, to help encourage a more collaborative design experience, rather than rapid fire mass-inclusion summit sessions. So we have two 40-minute long slots, and one whole day of contributor meetup.[1] Our etherpad topics page has received quite a few additions

Re: [openstack-dev] [all][oslo] projects still using obsolete oslo modules

Thanks you for this script! Status of novaclient: Work around porting to use oslo.i18n is finished. Also, latest code from incubator is synced. On Mon, Oct 13, 2014 at 4:20 PM, Doug Hellmann wrote: > I’ve put together a little script to generate a report of the projects > using modules that use

Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

On 9/25/2014 11:09 AM, Day, Phil wrote: Hi Jay, So just to be clear, are you saying that we should generate 2 notification messages on Rabbit for every DB update? That feels like a big overkill for me. If I follow that login then the current state transition notifications should also be ch

Re: [openstack-dev] [neutron] allow-mac-to-be-updated

On 10/14/2014 05:19 AM, Gary Kotton wrote: Hi, I am really in favor of this. The implementation looks great! Nova can surely benefit from this and we can make Neutron allocations at the API level and save a ton of complexity at the compute level. Kudos! Thanks Gary On 10/13/14, 11:31 PM, "Chuck

[openstack-dev] [Glance] Virtual Mini-Summit

We've planned a online + IRC mini-summit for discussing Glance topics prior to the Paris summit. Please find the agenda as well as the topics which are currently included for the same in this [0] etherpad. If you've a topic in mind just for this virtual summit, please feel free to add so in the

Re: [openstack-dev] [OpenStack] [Barbican] [Cinder] Cinder and Barbican

Hello Giuseppe, There have been blueprints related to this, such as here: https://blueprints.launchpad.net/cinder/+spec/encryption-with-barbican I don't think all the necessary pieces for this feature have landed as of yet though...cc-ing Joel and Nate in case they wanted to weigh in here. Tha

Re: [openstack-dev] [All] Maintenance mode in OpenStack during patching/upgrades

On Tue, Sep 9, 2014 at 2:19 PM, Mike Scherbakov wrote: >> On Tue, Sep 9, 2014 at 6:02 PM, Clint Byrum wrote: > The idea is not simply deny or hang requests from clients, but provide them > "we are in maintenance mode, retry in X seconds" > >> You probably would want 'nova host-servers-migrate ' >

[openstack-dev] [Glance][QA] python-glanceclient untestable in Python 3.4

As part of an effort to deprecate our specialized testing platform for Python 3.3, many of us have been working to confirm projects which currently gate on 3.3 can also pass their same test sets under Python 3.4 (which comes by default in Ubuntu Trusty). For the vast majority of projects, the diffe

Re: [openstack-dev] [All] Maintenance mode in OpenStack during patching/upgrades

On 10/16/2014 7:26 PM, Christopher Aedo wrote: On Tue, Sep 9, 2014 at 2:19 PM, Mike Scherbakov wrote: On Tue, Sep 9, 2014 at 6:02 PM, Clint Byrum wrote: The idea is not simply deny or hang requests from clients, but provide them "we are in maintenance mode, retry in X seconds" You probabl

Re: [openstack-dev] [kolla] on Dockerfile patterns

On Wed, 15 Oct 2014 08:19:03 PM Clint Byrum wrote: > > > I think it would be a good idea for containers' filesystem contents to > > > be a whole distro. What's at question in this thread is what should be > > > running. If we can just chroot into the container's FS and run > > > apt-get/yum > > > i

Re: [openstack-dev] [kolla] on Dockerfile patterns

On Fri, Oct 17, 2014 at 12:44:50PM +1100, Angus Lees wrote: > You just need to find the pid of a process in the container (perhaps using > docker inspect to go from container name -> pid) and then: > nsenter -t $pid -m -u -i -n -p -w Note also that the 1.3 release of Docker ("any day now") will

Re: [openstack-dev] [Keystone] external AuthN Identity Backend

On 10/16/2014 12:30 PM, Dave Walker wrote: > Hi, > > I think I considered the Federated plugin as a mismatch as it dealt > with 'remote' auth rather than 'external' auth. I thought it was for > purely handling SSO / SAML2, and not being subordinate to auth with > the webserver. > > I'll dig in

[openstack-dev] [all] add cyclomatic complexity check to pep8 target

Hi all I came across some tools [1] & [2] that we could use to make sure we don't increase our code complexity. Has anyone had any experience with these or other tools? radon is the underlying reporting tool and xenon is a "monitor" - meaning it will fail if a threshold is reached. To save you

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Thu, Oct 16, 2014 at 8:11 PM, Angus Salkeld wrote: > Hi all > > I came across some tools [1] & [2] that we could use to make sure we don't > increase our code complexity. > > Has anyone had any experience with these or other tools? > Flake8 (and thus hacking) has built in McCabe Complexity c

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

I ran this tool on Keystone and liked the results - the two methods that ranked D should certainly be refactored. It also matched a few methods in openstack/common. But flake8 supports complexity checking already, using mccabe. Just enable complexity checking with: $ flake8 --max-complexity 20

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

I agree we should use flake8 built-in if at all possible. I complexity checking will definitely help us in the long run keeping code maintainable. +1 from me.  — Morgan Fainberg On October 16, 2014 at 20:45:35, Joe Gordon ([email protected]) wrote: > On Thu, Oct 16, 2014 at 8:11 PM, Angus

Re: [openstack-dev] [Glance][QA] python-glanceclient untestable in Python 3.4

Hi Jeremy, Thanks for the heads up. Is there a bug opened to track this? If not, I'm going to open one and dig into it. Cheers. On 17/10/14 14:17, Jeremy Stanley wrote: > As part of an effort to deprecate our specialized testing platform > for Python 3.3, many of us have been working to confirm p

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

I think nova wins. We have: ./nova/virt/libvirt/driver.py:3736:1: C901 'LibvirtDriver._get_guest_config' is too complex (67) Michael On Fri, Oct 17, 2014 at 2:45 PM, Dolph Mathews wrote: > I ran this tool on Keystone and liked the results - the two methods that > ranked D should certainly be re

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Fri, Oct 17, 2014 at 1:40 PM, Joe Gordon wrote: > > > On Thu, Oct 16, 2014 at 8:11 PM, Angus Salkeld > wrote: > >> Hi all >> >> I came across some tools [1] & [2] that we could use to make sure we >> don't increase our code complexity. >> >> Has anyone had any experience with these or other t

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Thu, Oct 16, 2014 at 8:53 PM, Morgan Fainberg wrote: > I agree we should use flake8 built-in if at all possible. I complexity > checking will definitely help us in the long run keeping code maintainable. > Well this is scary: ./nova/virt/libvirt/driver.py:3736:1: C901 'LibvirtDriver._get_gue

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Thu, Oct 16, 2014 at 10:09 PM, Joe Gordon wrote: > > On Thu, Oct 16, 2014 at 8:53 PM, Morgan Fainberg < > [email protected]> wrote: > >> I agree we should use flake8 built-in if at all possible. I complexity >> checking will definitely help us in the long run keeping code maintainable.

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Fri, Oct 17, 2014 at 2:09 PM, Joe Gordon wrote: > > On Thu, Oct 16, 2014 at 8:53 PM, Morgan Fainberg < > [email protected]> wrote: > >> I agree we should use flake8 built-in if at all possible. I complexity >> checking will definitely help us in the long run keeping code maintainable.

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On 17/10/14 15:23, Angus Salkeld wrote: > Thanks for that, I mostly copied your patch for Heat: > https://review.openstack.org/#/c/129126/ > > I wish it would print out the value for all the modules tho', that is > what is nice about radon. It's a little horrible, but we can do the same thing: (

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

I like the idea of measuring complexity. I looked briefly at `python -m mccabe`. It seems to measure each method independently. Is this really fair? If I have a class with some big methods, and I break it down into more numerous and smaller methods, then the largest method gets smaller, but

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Fri, Oct 17, 2014 at 3:24 PM, Mike Spreitzer wrote: > I like the idea of measuring complexity. I looked briefly at `python -m > mccabe`. It seems to measure each method independently. Is this really > fair? I think it is a good starting point. You still need to write methods that do one t

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Fri, Oct 17, 2014 at 2:39 PM, Joe Gordon wrote: > > First step in fixing this, put a cap on it: > https://review.openstack.org/129125 > Thanks Joe - I've just put up a similar patch for Ironic: https://review.openstack.org/129132 -- Michael Davies mich...@the-davi

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

Excerpts from Mike Spreitzer's message of 2014-10-16 22:24:30 -0700: > I like the idea of measuring complexity. I looked briefly at `python -m > mccabe`. It seems to measure each method independently. Is this really > fair? If I have a class with some big methods, and I break it down into >

Re: [openstack-dev] [all] add cyclomatic complexity check to pep8 target

On Fri, Oct 17, 2014 at 03:03:43PM +1100, Michael Still wrote: > I think nova wins. We have: > > ./nova/virt/libvirt/driver.py:3736:1: C901 > 'LibvirtDriver._get_guest_config' is too complex (67) IMHO this tool is of pretty dubious value. I mean that function is long for sure, but it is by no mea