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

I’m glad to see this topic getting some focus once again. :-) >From several of the administrators I talk with, when they think of putting a >host into maintenance mode, the common requests I hear are: 1. Don’t schedule more VMs to the host 2. Provide an optional way to automatically migrate all

Re: [openstack-dev] DB Datasets CI broken

On Sat, Oct 18, 2014 at 11:02 AM, Jeremy Stanley wrote: > On 2014-10-18 10:45:23 +1100 (+1100), Michael Still wrote: > [...] >> Is it possible to add a verification step to nodepool so that it >> doesn't mark a new image as ready unless it passes some basic sanity >> checks? > > Back in the before

Re: [openstack-dev] [api] Request Validation - Stoplight

Hi Amit, Keeping in mind this viewpoint is nothing but my own personal view, my recommendation would be to not mandate the use of a particular validation framework, but to instead define what kind of validation clients should expect the server to perform in general. For example, I would expect

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

Chris, See answers inline. I don't have any concrete answers as to how to deal with some of questions you brought up, but I do have some more detail that may be useful to further the discussion. On 10/17/2014 11:03 AM, Chris Dent wrote: On Thu, 16 Oct 2014, Jim Mankovich wrote: What I would lik

Re: [openstack-dev] [infra] [all] config repository rename to system-config

As previously announced, we have now completed renaming of the following Git repositories: openstack-infra/config -> openstack-infra/system-config stackforge/glance-formula -> stackforge/glance-salt-formula stackforge/keystone-formula -> stackforge/keystone-salt-formula You will want

Re: [openstack-dev] DB Datasets CI broken

On 2014-10-18 10:45:23 +1100 (+1100), Michael Still wrote: [...] > Is it possible to add a verification step to nodepool so that it > doesn't mark a new image as ready unless it passes some basic sanity > checks? Back in the beforetime, when devstack-gate had scripts which managed the worker pool

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

On Oct 16, 2014 8:24 AM, "Dean Troyer" wrote: > > > > 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 t

Re: [openstack-dev] DB Datasets CI broken

This was a bad image in nodepool. I've rebuilt the image and killed our pool of workers running the old image and things seem to be ok now. I'm in the process of enqueueing rechecks for every failed turbo-hipster run now, but they'll take some time to all get executed. Thanks for your patience eve

[openstack-dev] DB Datasets CI broken

Hi, I've just noticed that the DB Datasets CI (the artist formerly known as turbo hipster) is failing for many patches. I'm looking into it now. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://li

[openstack-dev] [TripleO] CI report : 04/10/2014 - 17/10/2014

Hi All, Nothing to report since the last report, 2 weeks of no breakages. thanks, Derek. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

On 2014-10-17 16:17:39 +0100 (+0100), Louis Taylor wrote: > This looks like a continuation of the old PYTHONHASHSEED bug: > > https://launchpad.net/bugs/1348818 The underlying design choices in python-glanceclient's tests do cause both problems (can't run with a random hash seed, but also can

[openstack-dev] [api] Request Validation - Stoplight

Hi API Working Group Last night at the Openstack Meetup in Atlanta, a group of us discussed how request validation is being performed over various projects and how some teams are using pecan wsmi, or warlock, jsonschema etc. Each of these libraries have their own pro’s and con’s. My understand

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

On Thu, 16 Oct 2014, Jim Mankovich wrote: What I would like to propose is dropping the ipmi string from the name altogether and appending the Sensor ID to the name instead of to the Resource ID. So, transforming the above to the new naming would result in the following: | Name

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

docker exec would be awesome. So... whats redhat's stance on docker upgrades here? I'm running centos7, and dockers topped out at docker-0.11.1-22.el7.centos.x86_64. (though redhat package versions don't always reflect the upstream version) I tried running docker 1.2 binary from docker.io but s

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

On Oct 15, 2014, at 5:52 AM, Christopher Yeoh mailto:cbky...@gmail.com>> wrote: We don't require new templates as part of nova-specs and api changes don't necessarily change the api sample tpl files. We do ask for some jsonschema descriptions of the new APIs input but they work pretty well in t

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

I would also advise pinning the version of mccabe we’re using. Mccabe was originally a proof-of-concept script that Ned Batchelder wrote and which Tarek Ziade vendored into Flake8. After we split it out in v2 of Flake8, we’ve found several (somewhat serious) reporting problems with the tool. Curren

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

On Fri, Oct 17, 2014 at 03:01:22PM +, Jeremy Stanley wrote: > Gah! You'd think *I* would know better at this point--sorry about > that... I've now opened https://launchpad.net/bugs/1382582 to track > this. Thanks for any assistance you're able to provide! This looks like a continuation of the

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

On 2014-10-17 16:57:59 +1300 (+1300), Fei Long Wang wrote: > 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. Gah! You'd think *I* would know better at this point--sorry about that... I've now opened https://launchpad.net/bugs/1

[openstack-dev] [Nova] Turbo hipster problems

Hi, Anyone aware why Turbo his peter is failing with: real-db-upgrade_nova_percona_user_002:th-percona Exception: [Errno 2] No such file or directory: '/var/lib/turbo-hipster/datasets_user_002' in 0s Thanks Gary ___ OpenStack-dev mai

[openstack-dev] [Elections] Results of the TC Election

Please join me in congratulating the 6 newly elected members of the TC. * Monty Taylor * Sean Dague * Doug Hellmann * Russell Bryant * Anne Gentle * John Griffith Full results: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4 Thank you to all candidates who stood for election,

[openstack-dev] [novaclient] E12* rules

Hi everyone! I'm working on enabling E12* PEP8 rules in novaclient(status of my work listed below). Imo, PEP8 rules should be ignored only in extreme cases/for important reasons and we should decrease a number of ignored rules. This helps to keep code in more strict, readable form, which is very i

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

Thierry Carrez wrote on 10/17/2014 11:28:56 AM: > From: Thierry Carrez > To: openstack-dev@lists.openstack.org > Date: 10/17/2014 11:31 AM > Subject: Re: [openstack-dev] [QA] Proposal: A launchpad bug description template > > Markus Zoeller wrote: > > TL;DR: A proposal for a template for launc

[openstack-dev] Cell Initialization

Hi, I was trying to create cells under openstack using devstack. My setup contains 3 machines. One toplevel and 2 compute cells. I'm following this documentation, http://docs.openstack.org/trunk/config-reference/content/section_compute-cells.html . Both these cells instantiation are generating er

[openstack-dev] [Horizon] Template Blueprint

Hello Horizoners, I would like to draw your attention to the excellent Template Blueprint[1] which David created. The aim of this is to create a template which will be used for all future blueprints. This way we can try to ensure that enough information/detail is provided in blueprints, as we

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

On Fri, Oct 17, 2014 at 9:53 AM, Jastrzebski, Michal wrote: > > >> -Original Message- >> From: Florian Haas [mailto:flor...@hastexo.com] >> Sent: Thursday, October 16, 2014 10:53 AM >> To: OpenStack Development Mailing List (not for usage questions) >> Subject: Re: [openstack-dev] [Nova] A

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

On 10/17/2014 05:10 AM, Chris Dent wrote: On Fri, 17 Oct 2014, Daniel P. Berrange wrote: IMHO this tool is of pretty dubious value. I mean that function is long for sure, but it is by no means a serious problem in the Nova libvirt codebase. The stuff it complains about in the libvirt/config.py

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

Clint Byrum wrote: > * The Ops Summit is Wendesday/Thursday [3], which overlaps with these > sessions. I am keenly interested in gathering more contribution from > those already operating and deploying OpenStack. It can go both ways, > but I think it might make sense to have more ops-centric

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

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. Note that Launchpad doesn't support bug entry templates. You can display "bug reporting guidelines" which appear under the textbox, but that's about

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

On 17 October 2014 02:28, Matt Riedemann wrote: > > > 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

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

Hi Jim, On 10/16/2014 07:23 PM, Jim Mankovich wrote: 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 ce

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

On 10/17/2014 05:57 AM, Fei Long Wang wrote: > 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. Hey Fei Long, Thanks for taking care of this, please keep me in the loop. @Jeremy: Thanks for the heads up Flavio

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

On Fri, 17 Oct 2014, Daniel P. Berrange wrote: IMHO this tool is of pretty dubious value. I mean that function is long for sure, but it is by no means a serious problem in the Nova libvirt codebase. The stuff it complains about in the libvirt/config.py file is just incredibly stupid thing to hig

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

On Thu, 16 Oct 2014, Lars Kellogg-Stedman wrote: 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

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

> -Original Message- > From: Florian Haas [mailto:flor...@hastexo.com] > Sent: Thursday, October 16, 2014 10:53 AM > To: OpenStack Development Mailing List (not for usage questions) > Subject: Re: [openstack-dev] [Nova] Automatic evacuate > > On Thu, Oct 16, 2014 at 9:25 AM, Jastrzebski,

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

I like measuring code metrics, and I definitely support Joe's change here. I think of McCabe complexity as a proxy for testability and readability of code, both of which are IMO actual real problems in the nova codebase. If you are an experienced openstack dev you might find the code easy to move a

Re: [openstack-dev] [Neutron] BGPVPN implementation discussions

Good news, +1 2014-10-17 0:48 GMT+08:00 Mathieu Rohon : > 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 f