Re: [openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

Hey, turbo hipster already knows how to upgrade major releases, so adding this should be possible. That said, I've been travelling all day so haven't had a chance to look at this. If Josh doesn't beat me to it, I will take a look when I get to my hotel tonight. (We should also note that we can ju

[openstack-dev] [glance] Why no DB index on sort parameters

Hi All, I see that glance supports arbitrary sort parameters and the default is "created_at" while listing images. Is there any reason why we don't have index over these fields? If we have an index over these fields then we would avoid a full table scan to do sorting. IMO at least the created_at f

Re: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated

Hey, turbo-hipster is no longer testing downgrades as per the TC decision. The CI bot now passes on that change. Cheers, Josh Rackspace Australia On 4/20/15 10:16 PM, Sean Dague wrote: Awesome, thanks Josh. On 04/20/2015 07:14 AM, Joshua Hesketh wrote: Hi Sean, Thanks for your work on th

Re: [openstack-dev] Regarding openstack swift implementation

Hello, On Tue, Apr 21, 2015 at 7:34 AM, Subbulakshmi Subha < subbulakshmisubh...@gmail.com> wrote: > I want to simulate it one javasim,so I want to know how are objects stored > in the partitions in swift.I computed the md5 hash of the objects url, n > the medium of storage is hashmap,so I want t

Re: [openstack-dev] Regarding openstack swift implementation

I want to simulate it one javasim,so I want to know how are objects stored in the partitions in swift.I computed the md5 hash of the objects url, n the medium of storage is hashmap,so I want to know how doea it store it there?is there any algorithm for it? On 21-Apr-2015 10:59 AM, "Madhuri Rai" wr

Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad

On 04/21/2015 03:45 AM, Kaneko Takehiro wrote: Andreas, Our project repository matches the project in Launchpad but the bug status doesn't change(Triaged => In Progress). Bug: https://bugs.launchpad.net/python-rack/+bug/1446058 Gerrit: https://review.openstack.org/#/c/175272/ that first chang

Re: [openstack-dev] Regarding openstack swift implementation

Hi, You can go through below link to get started. http://docs.openstack.org/developer/swift/development_saio.html Thanks Madhuri Kumari On Tue, Apr 21, 2015 at 2:09 PM, Subbulakshmi Subha < subbulakshmisubh...@gmail.com> wrote: > Hi, > I am trying to simulate openstack swift.could you ple

[openstack-dev] Regarding openstack swift implementation

Hi, I am trying to simulate openstack swift.could you please help me with getting started.what are all the details I should be knowing to store objects on swift? __ OpenStack Development Mailing List (not for usage question

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

Hi, Edgar Some docs are still in private branch. Can we move to public branch for reviewing & submitting patches? Thanks, -Ruijing From: Edgar Magana [mailto:edgar.mag...@workday.com] Sent: Saturday, April 18, 2015 2:25 AM To: OpenStack Development Mailing List (not for usage questions) Subject

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

On Tue, Apr 21, 2015 at 12:33 PM, x Lyn wrote: > Since cloudwatch is deprecated, is there any plan to remove it away from > codes? Or still has some functions depend on this service? > No plans as yet, but all you have to do is not run the binary (heat-api-cw). > > 2015-04-18 2:29 GMT+08:00 Za

Re: [openstack-dev] [heat] is cloudwatch really deprecated?

Since cloudwatch is deprecated, is there any plan to remove it away from codes? Or still has some functions depend on this service? 2015-04-18 2:29 GMT+08:00 Zane Bitter : > On 17/04/15 13:54, Matt Fischer wrote: > >> On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter > > wr

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

Hi Mike, Could you please take a look at the results and consider re-integrating the driver? We the Oracle ZFSSA team would like to target the Kilo RC deadline if possible. Thank you, Diem. On 4/20/15 3:47 PM, Diem Tran wrote: Hi Mike, Oracle ZFSSA iSCSI CI is now reporting test results.

Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad

Andreas, Our project repository matches the project in Launchpad but the bug status doesn't change(Triaged => In Progress). Bug: https://bugs.launchpad.net/python-rack/+bug/1446058 Gerrit: https://review.openstack.org/#/c/175272/ The following change has been merged.( https://review.openstack.or

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

On Mon, Apr 20, 2015 at 1:18 PM, Duncan Thomas wrote: > Hi Diem > > It appears the CI failed to pass on any of the 5 reviews you linked to. > Are there any examples of the CI passing? > > I don't see any passing runs in the last 20 comments left by 'Oracle ZFSSA CI' http://paste.openstack.org/sh

Re: [openstack-dev] [api] Minor changes to API

On 04/20/2015 08:07 PM, Ian Wells wrote: On 20 April 2015 at 15:23, Matthew Treinish > wrote: On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote: > It would be nice to have a consistent policy here; it would make future > decision making easier

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Ian, If you were thinking instead to provide coverage *tools* that were easy for > developers to use, Hm, seems like you missed the point. This "gate job" can be run like unit tests "tox -e cover". That will point you on the missing lines that are introduced in your patch. As a dev, I would

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

It'd be nice to having something like https://coveralls.io/features which afaik just reports back on pull requests (and doesn't try to enforce much of anything, aka non-voting). For example: https://github.com/aliles/funcsigs/pull/13 In general it'd be neat if we could more easily interconnect

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

On 20 April 2015 at 07:40, Boris Pavlovic wrote: > Dan, > > IMHO, most of the test coverage we have for nova's neutronapi is more >> than useless. It's so synthetic that it provides no regression >> protection, and often requires significantly more work than the change >> that is actually being a

Re: [openstack-dev] [api] Minor changes to API

On 20 April 2015 at 15:23, Matthew Treinish wrote: > On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote: > > It would be nice to have a consistent policy here; it would make future > > decision making easier and it would make it easier to write specs if we > > knew what was expected and th

[openstack-dev] PyCon-AU Openstack miniconf CFP open

Hi everybody - I'd like to call attention to the PyCon-AU OpenStack miniconf. http://2015.pycon-au.org/cfp Pycon-au is an excellent conference, and the OpenStack miniconf is now in its third year - we're really getting into the swing of things. Please submit a paper to the main conference CFP -

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 21/04/15 11:01, Angus Salkeld wrote: On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M > wrote: As an Op, a few things that come to mind in that category are: * RDO packaging (stated earlier). If its not easy to install, its not going to be deployed as m

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M wrote: > As an Op, a few things that come to mind in that category are: > * RDO packaging (stated earlier). If its not easy to install, its not > going to be deployed as much. I haven't installed it yet, because I haven't > had time to do much other

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

Thanks Kevin, all good suggestions. Re Horizon UI, yes, we even have a blueprint to track that, but seems the owner didn't complete it. FWIW, I would suggest to put it on the todo list of L. [1] https://blueprints.launchpad.net/zaqar/+spec/marconi-horizon-integration On 21/04/15 10:38, Fox, Kevin

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

As an Op, a few things that come to mind in that category are: * RDO packaging (stated earlier). If its not easy to install, its not going to be deployed as much. I haven't installed it yet, because I haven't had time to do much other then yum install it... * Horizon UI * Heat Resources. (Some

[openstack-dev] [devstack][octavia] Loading one devstack plugin from another devstack plugin.

Hi Devstack people, I have developed two devstack plugins (for neutron-lbaas and octavia), and I think I am stretching the capabilities of the devstack plugin architecture. Neutron-lbaas is the load balancer framework for OpenStack. By default it uses a fairly simple haproxy-based agent to act

Re: [openstack-dev] [api] Minor changes to API

On Mon, Apr 20, 2015 at 03:10:40PM -0700, Ian Wells wrote: > On 20 April 2015 at 13:02, Kevin L. Mitchell > wrote: > > > On Mon, 2015-04-20 at 13:57 -0600, Chris Friesen wrote: > > > > However, minor changes like that could still possibly break clients > > that are not > > > > expecting them. Fo

Re: [openstack-dev] [puppet] bug triage day

I think this is a good idea. We'd need an etherpad or may I suggest google spreadsheet of the bugs so people can pick them off, especially since we're all on different TZs and many of us will not be able to dedicate the full 8 hours to it. On Mon, Apr 20, 2015 at 3:20 PM, Emilien Macchi wrote: >

Re: [openstack-dev] [api] Minor changes to API

On 20 April 2015 at 13:02, Kevin L. Mitchell wrote: > On Mon, 2015-04-20 at 13:57 -0600, Chris Friesen wrote: > > > However, minor changes like that could still possibly break clients > that are not > > > expecting them. For example, a client that uses the json response as > arguments > > > to a

Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0

On 21 April 2015 at 09:27, Thomas Goirand wrote: > > > On 04/20/2015 12:10 PM, Victor Stinner wrote: >>> >>> If there's nothing majorly wrong mid-L, I'd like to release 1.0.0 just >>> to get us into 'ok its stable' mentality. >> >> >> I read that many packages modify the source code of libraries a

[openstack-dev] [tripleo] Adventures in QuintupleO

I've been spending some time getting quintupleo working on top of a Juno RDO OpenStack. I'm at a point now where I think it is worth putting effort into making it easy for anyone to try this. Ben Nemec has done the hard work of proving this is possible[1] resulting in the repo he uses to bring

Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0

On 04/20/2015 12:10 PM, Victor Stinner wrote: If there's nothing majorly wrong mid-L, I'd like to release 1.0.0 just to get us into 'ok its stable' mentality. I read that many packages modify the source code of libraries and applications to avoid a dependency to pbr at runtime. What's the sta

[openstack-dev] [puppet] bug triage day

Hi, We have around 142 bugs without fix for now in our modules [1]. Some folks in our group raised an idea where we could do a bug triage day sometimes. I've created an etherpad so we can have a list of people interested to participate [2] in this work. Feel free to bring your name, and we will

[openstack-dev] MySQL charset collation for `db sync` commands

Hi, I notified Glance (and probably other projects) are running the db_sync with 'utf8_general_ci' by default. * Can we change it? I've looked in Glance & oslo.db, I've not seen anything. * Can we configure it to stop enforcing this collation? Some deployments are running 'utf8_unicode_ci' * why

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

Hi Ramy, While I agree, in principal, with this line of thinking and goal, my concern will be how much extra work is it going to create for existing CI owners? Our Ci system has been stable for a long time, and we put in a good amount of effort to get it to that point. Our CI is not based upon zuu

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M wrote: > Another parallel is Manilla vs Swift. Both provides something like a share > for users to store files. > > The former is a multitenant api to provision non multitenant file shares. > The latter is a multitenant api to provide file sharing. >

Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty

On 20 April 2015 at 04:54, Morgan Fainberg wrote: >> Could you enlarge on what 'coordinating the requirements' means? >> > > This is simply a choice to adhere to the global-requirements for a given > release (e.g. Liberty) that nova (and other projects) adhere to. We won't be > doing "a release w

Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty

On 21 April 2015 at 03:24, Sean Dague wrote: > On 04/20/2015 11:20 AM, Morgan Fainberg wrote: ... >> Re publishing milestones: TBD. I wanted to discuss that with release >> management team and see if that made sense. I believe it does make >> sense, but have not determined that for sure. > > The r

Re: [openstack-dev] [oslo][policy][neutron] oslo.policy API is not powerful enough to switch Neutron to it

On 04/17/2015 08:45 AM, Ihar Hrachyshka wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, tl;dr neutron has special semantics for policy targets that relies on private symbols from oslo.policy, and it's impossible to introduce this semantics into oslo.policy itself due to backwards compa

Re: [openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

Hi Diem It appears the CI failed to pass on any of the 5 reviews you linked to. Are there any examples of the CI passing? On 20 April 2015 at 20:47, Diem Tran wrote: > Hi Mike, > > Oracle ZFSSA iSCSI CI is now reporting test results. It is configured to > run against the ZFSSA iSCSI driver. You

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Morgan, Thank you for your input. I improved coverage job in this patch: https://review.openstack.org/#/c/175557/1 Now: * It is based on missing lines and not coverage percentage. * It shows nice messages and coverage diffs: Allowed to introduce missing lines : 8 Missing lines in master

[openstack-dev] [all] Call for testing - pbr master

Hi, we think pbr's master branch is ready for consumption again, but it would be nice to have some early adopters confirm this - the sem-ver automatic version calculation that we discussed oh a year ago now is all ready for use, but it's possible there are bugs lying in wait. I'd love it if, if yo

Re: [openstack-dev] [api] Minor changes to API

On Mon, 2015-04-20 at 13:57 -0600, Chris Friesen wrote: > > However, minor changes like that could still possibly break clients that > > are not > > expecting them. For example, a client that uses the json response as > > arguments > > to a method via **kwargs would start seeing TypeErrors for u

Re: [openstack-dev] [api] Minor changes to API

On 04/20/2015 01:19 PM, Douglas Mendizabal wrote: Hi openstack-dev@ I was wondering if the API Working Group had an opinion on how to deal with minor changes to the api? For example, what if you wanted to add a new attribute to a JSON response? I would think that a minor change like that could

Re: [openstack-dev] [all] [api] gabbi: A tool for declarative testing of APIs

I wanted to make a quick update on the latest happenings with gabbi[0], the tool I've created to do "declarative" testing of OpenStack APIs (starting with Ceilometer and Gnocchi). * Jay Pipes and I are doing a presentation "API Matters" at summit. The latter of half of that will be me noodling

[openstack-dev] [OpenStack-Infra][cinder] Could you please re-consider Oracle ZFSSA iSCSI Driver

Hi Mike, Oracle ZFSSA iSCSI CI is now reporting test results. It is configured to run against the ZFSSA iSCSI driver. You can see the results here: https://review.openstack.org/#/q/reviewer:%22Oracle+ZFSSA+CI%22,n,z Below are some patchsets that the CI reports: https://review.openstack.org/#/c

Re: [openstack-dev] [Glance] Open glance-drivers to all glance-cores

> -Original Message- > From: Flavio Percoco [mailto:fla...@redhat.com] > Sent: 20 April 2015 15:04 > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] [Glance] Open glance-drivers to all glance-cores > > Hello Glance folks, and not Glance folks :D > > Here's a thought. I be

Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0

On 21 April 2015 at 00:22, Victor Stinner wrote: >> I believe Redhat patch it out. I don't think they should need to, >> since we have explicit knobs for distros to use. > > pbr pulls pip which we don't want in RHEL. Example of patches in RDO: > > https://github.com/redhat-openstack/nova/commit/a1

[openstack-dev] [api] Minor changes to API

Hi openstack-dev@ I was wondering if the API Working Group had an opinion on how to deal with minor changes to the api? For example, what if you wanted to add a new attribute to a JSON response? I would think that a minor change like that could be done without having to create a new versioned

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

That's what I needed to know, thanks :) Michael On Mon, Apr 20, 2015 at 12:11 PM Fox, Kevin M wrote: > Another parallel is Manilla vs Swift. Both provides something like a share > for users to store files. > > The former is a multitenant api to provision non multitenant file shares. > The latte

[openstack-dev] [Ironic] Weekly subteam status report

Hi, Following is the subteam report for Ironic. As usual, this is pulled directly from the Ironic whiteboard[0] and formatted. Bugs (dtantsur) (As of Mon, 20 Apr, 14:00 UTC) Open: 143 8 new, 34 in progress, 0 critical, 10 high and 8 incomplete kilo-rc-potential triaged: https:/

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

Another parallel is Manilla vs Swift. Both provides something like a share for users to store files. The former is a multitenant api to provision non multitenant file shares. The latter is a multitenant api to provide file sharing. Cue is a multitenant api to provision non multitenant queues. Za

Re: [openstack-dev] [Fuel] Nominate Andrey Skedzinskiy for fuel-qa(devops) core

Yes, finally it happened! First review was https://review.openstack.org/#/c/175366/ Nastya. On Tue, Apr 14, 2015 at 1:33 PM, Aleksey Kasatkin wrote: > +1 > > > Aleksey Kasatkin > > > On Tue, Apr 14, 2015 at 1:20 PM, Anastasia Urlapova < > aurlap...@mirantis.com> wrote: > >> Andrey, >> congratu

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 04/20/2015 02:22 PM, Michael Krotscheck wrote: > What's the difference between openstack/zaqar and stackforge/cue? > Looking at the projects, it seems like zaqar is a ground-up > implementation of a queueing system, while cue is a provisioning api for > queuing systems that could include zaqar,

Re: [openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)

+1 : That's a great insight into efficient cross-project communication. Thanks, -Nikhil From: Boris Pavlovic Sent: Monday, April 20, 2015 11:38 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [all] Using project-specific channels for offici

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

What's the difference between openstack/zaqar and stackforge/cue? Looking at the projects, it seems like zaqar is a ground-up implementation of a queueing system, while cue is a provisioning api for queuing systems that could include zaqar, but could also include rabbit, zmq, etc... If my understa

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

On 20/04/15 18:01, Clint Byrum wrote: > Excerpts from Boris Pavlovic's message of 2015-04-18 18:30:02 -0700: >> Hi stackers, >> >> Code coverage is one of the very important metric of overall code quality >> especially in case of Python. It's quite important to ensure that code is >> covered fully

[openstack-dev] [Neutron][Ironic] Setting IPXE tag for dnsmasq

Hi, In the following patch, I had a question about setting the IPXE tag by default. https://review.openstack.org/#/c/172040/ Basically, I'm unsure if we want to set this tag by default. I freely admit that I'm not an expert in PXE, but my thinking is that rather than enabling it by default, we s

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Clint, Anyway, interesting thoughts from everyone. I have to agree with those > that say this isn't reliable enough to make it vote. Non-voting would be > interesting though, if it gave a clear score difference, and a diff of > the two coverage reports. I think this is more useful as an automated

[openstack-dev] [mistral] Team meeting minutes - 04/20/2015

Thanks for joining today! Meeting minutes: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-04-20-16.22.html Meeting log: http://eavesdrop.openstack.org/meetings/mistral/2015/mistral.2015-04-2

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Excerpts from Boris Pavlovic's message of 2015-04-18 18:30:02 -0700: > Hi stackers, > > Code coverage is one of the very important metric of overall code quality > especially in case of Python. It's quite important to ensure that code is > covered fully with well written unit tests. > > One of th

Re: [openstack-dev] [neutron] [QoS] weekly meeting - update

> On 20/4/2015, at 16:03, Kyle Mestery wrote: > > On Mon, Apr 20, 2015 at 8:44 AM, Ihar Hrachyshka > wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: > > Thank you Irena, > > > > I believe this las

[openstack-dev] [Infra] Meeting Tuesday April 21st at 19:00 UTC

Hi everyone, The OpenStack Infrastructure (Infra) team is having our next weekly meeting on Tuesday April 21st, 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 interest

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

On 09:30 Apr 20, Jay Pipes wrote: > On 04/20/2015 07:13 AM, Sean Dague wrote: > >On 04/18/2015 09:30 PM, Boris Pavlovic wrote: > >>Hi stackers, > >> > >>Code coverage is one of the very important metric of overall code > >>quality especially in case of Python. It's quite important to ensure > >>tha

Re: [openstack-dev] [nova][python-novaclient] microversion implementation on client side

Hello, So, AFAIK, there is currently a problem with this. If you make a request for, let's say v2.2 microversion, you will want to execute: nova --os-compute-api-version 2.2 keypair-list But, from my experience, that does not work as expected. Instead of the plugins/v3/ module, it is executed

Re: [openstack-dev] [taskflow][glance][debian] Issue with ordereddict

It should be fine to remove it on 2.7+ The team can't yet remove it from its requirements.txt until we drop 2.6 support (which should happen soon(ish) afaik), but the way that import is used is that it always tries to import the one from collections before falling back to the one from the libr

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 20/04/15 14:08 +, Fox, Kevin M wrote: RDO packaging would go a long way for us. Also what about oslo support? We have a second rabbit for sahara/trove/ designate for reasons I wont get into here on one cloud that could just be made to use Zaqar instead? This is exactly the kind of adopt

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

Thanks Ramy! I'd suggest that we use the cross-project session I proposed [1] for Liberty summit as a working session primarily focused on this work [2]. [1] https://docs.google.com/spreadsheets/d/1vCTZBJKCMZ2xBhglnuK3ciKo3E8UMFo5S5lmIAYMCSE/edit?usp=sharing [2] https://etherpad.openstack.org/p/l

Re: [openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)

Jeremy, Thank you for explanation, I missed this point before. Best regards, Boris Pavlovic On Mon, Apr 20, 2015 at 6:06 PM, Jay Pipes wrote: > +1, Jeremy. Excellent points. > > -jay > > > On 04/20/2015 10:59 AM, Jeremy Stanley wrote: > >> >> >> On 2015-04-17 16:26:29 +0300 (-0300), Boris Pav

Re: [openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)

+1 to that, the meeting channels help in a number of ways and it may be worthwhile stating that explicitly in the new project requirements. -amrith | -Original Message- | From: Jeremy Stanley [mailto:fu...@yuggoth.org] | Sent: Monday, April 20, 2015 10:59 AM | To: OpenStack Development

Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty

On Monday, April 20, 2015, Sean Dague wrote: > On 04/20/2015 11:20 AM, Morgan Fainberg wrote: > > > > > > On Monday, April 20, 2015, Sean Dague > > > wrote: > > > > On 04/19/2015 12:54 PM, Morgan Fainberg wrote: > > > > > > > > > On Sunday, April 19, 2015,

Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty

On 04/20/2015 11:20 AM, Morgan Fainberg wrote: > > > On Monday, April 20, 2015, Sean Dague > wrote: > > On 04/19/2015 12:54 PM, Morgan Fainberg wrote: > > > > > > On Sunday, April 19, 2015, Robert Collins > > > >

Re: [openstack-dev] [resend] [nova][libvirt] livemigration failed due to invalid of cpuset

On 04/19/2015 08:30 PM, Qiao, Liyong wrote: Hi all, Just resend to bring attentions Your bug is a duplicate of 1417667. If you haven't already, mark that you're affected by 1417667. This will help to indicate the level of severity of the problem. Chris ___

Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty

On Monday, April 20, 2015, Sean Dague wrote: > On 04/19/2015 12:54 PM, Morgan Fainberg wrote: > > > > > > On Sunday, April 19, 2015, Robert Collins > > > wrote: > > > > On 18 April 2015 at 15:20, Morgan Fainberg > > > wrote: > > > Hi everyone, > >

Re: [openstack-dev] Kerberization (and PKI-rization) of Horizon

On 04/19/2015 06:05 PM, Diogenes S. Jesus wrote: Hi man. I've seen your thread on OpenStack mailing list regarding using Kerberos on Horizon. I've been pulling my hair around this topic, however I'm trying to authen

Re: [openstack-dev] [neutron][stable] Bug 1414218 is not fixed on in neutron stable/juno branch

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/17/2015 12:56 AM, Carl Baldwin wrote: > Stephen, > > On Thu, Apr 16, 2015 at 4:21 PM, Ma, Stephen B. > wrote: >> As it stands currently, neutron on the stable/juno branch behaves >> as if https://review.openstack.org/#/c/164329/ was never mer

[openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)

On 2015-04-17 16:26:29 +0300 (-0300), Boris Pavlovic wrote: [...] > - Move meetings from #openstack-meeting to #openstack-rally chat. [...] Please don't. This means anyone who wants to be around in case an important topic comes up in your meeting has to leave themselves subscribed to an addition

Re: [openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)

+1, Jeremy. Excellent points. -jay On 04/20/2015 10:59 AM, Jeremy Stanley wrote: On 2015-04-17 16:26:29 +0300 (-0300), Boris Pavlovic wrote: [...] - Move meetings from #openstack-meeting to #openstack-rally chat. [...] Please don't. This means anyone who wants to be around in case an impor

Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd

I do agree with your suggestion. I will update the wiki and we will be using the #openstack-sprint IRC channel Cheers! Edgar From: Anne Gentle mailto:annegen...@justwriteclick.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.o

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

On 04/20/2015 08:54 AM, Flavio Percoco wrote: > Greetings, > > I'd like my first action as Zaqar's PTL to be based on reflections > and transparency with regards to what our past has been, to what > our present is and to what our future could be as a project and > community. Therefore, I'm sending

Re: [openstack-dev] [chef] A new Core member!

Congratulations!! The same for you JJ! Edgar From: Jay Lau mailto:jay.lau@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Sunday, April 19, 2015 at 10:52 PM To: "OpenStack Development Mailing List (not for

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

> Let's not mix the bad unit tests in Nova with the fact that code should > be fully covered by well written unit tests. I'm not using bad tests in nova to justify not having coverage testing. I'm saying that the argument that "more coverage is always better" has some real-life counter examples.

Re: [openstack-dev] [keystone] keystoneclient stable/icehouse broken

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2015 10:26 AM, Ihar Hrachyshka wrote: > On 04/20/2015 12:34 AM, Brant Knudson wrote: > > >> On Sun, Apr 19, 2015 at 3:07 PM, Brant Knudson > > wrote: > > >> Ever since the stable/icehouse branch was created for >> p

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Dan, IMHO, most of the test coverage we have for nova's neutronapi is more > than useless. It's so synthetic that it provides no regression > protection, and often requires significantly more work than the change > that is actually being added. It's a huge maintenance burden with very > little val

Re: [openstack-dev] [keystone] Changes to Spec Proposal Freeze and Feature Freeze dates for Keystone in Liberty

On 04/17/2015 11:31 PM, Morgan Fainberg wrote: As a quick update, for the Liberty cycle, keystone will be using the first milestone as our Spec Proposal Freeze (SPF), with Feature Proposal Freeze (API Impacting features must be code complete / ready for review / gating) at the second milestone

[openstack-dev] [chef] Status Meeting April 20, 2015

Hey Everyone! Here’s a link to the hangout: https://plus.google.com/hangouts/_/hoaevent/AP36tYenNDpCZC-E2cbqw7050E-AG7RI8SL6bWjGMyuYGKGkCJIcpw?authuser=0&hl=en And here’s the l

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

Gordon, +1. i don't think this would be a good idea as a non-voting job either as > it can/will lead to lazy reviews. It is similar to say let's remove unit/functional/pep8/pylint/"any other testing" because it will lead to lazy reviews. Best regards, Boris Pavlovic On Mon, Apr 20, 2015 at

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

> Well, I think there are very few cases where *less* coverage is better. IMHO, most of the test coverage we have for nova's neutronapi is more than useless. It's so synthetic that it provides no regression protection, and often requires significantly more work than the change that is actually bei

Re: [openstack-dev] Multi Region Designate

 Hi Kiall, Will appreciate if you can provide your comments on the email below. Regards, Anik From: Anik To: "openstack-dev@lists.openstack.org" Sent: Saturday, April 11, 2015 5:37 AM Subject: Re: [openstack-dev] Multi Region Designate Hi Kiall, Thanks for getting back.  Yes, I

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

> Date: Mon, 20 Apr 2015 07:13:31 -0400 > From: s...@dague.net > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if > coverage get worse after patch) > > On 04/18/2015 09:30 PM, Boris Pavlovic

[openstack-dev] [nova] Required data migrations in Kilo, need Turbo Hipster tests updated

This proposed patch requiring a data migration in Nova master is making Turbo Hipster face plant - https://review.openstack.org/#/c/174480/ This is because we will require Kilo deployers to fully migrate their flavor data from system_metadata to instance_extra before they upgrade to the next relea

Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)

RDO packaging would go a long way for us. Also what about oslo support? We have a second rabbit for sahara/trove/designate for reasons I wont get into here on one cloud that could just be made to use Zaqar instead? I do believe Zaqar is very important. Its been a long bumpy road, but you folks

[openstack-dev] [Glance] Open glance-drivers to all glance-cores

Hello Glance folks, and not Glance folks :D Here's a thought. I believe, based on the size of our project/community/reviewers team, we should just give access to all glance-cores to glance-drivers. Few considerations: 1) Many of our reviewers have been part of Glance even before I became part of

Re: [openstack-dev] [neutron] [QoS] weekly meeting - update

On Mon, Apr 20, 2015 at 8:44 AM, Ihar Hrachyshka wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: > > Thank you Irena, > > > > I believe this last minute change deserves an explanation, I asked > > Irena to write to the list on

[openstack-dev] [puppet] Weekly meeting #32

Hi, Tomorrow is our weekly meeting. Please look at the agenda [1]. Feel free to bring new topics and reviews/bugs if needed. Also, if you had any action, make sure you can give a status during the meeting or in the etherpad directly. See you tomorrow, [1] https://etherpad.openstack.org/p/puppet

Re: [openstack-dev] [neutron] [QoS] weekly meeting - update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2015 12:20 PM, Miguel Angel Ajo Pelayo wrote: > Thank you Irena, > > I believe this last minute change deserves an explanation, I asked > Irena to write to the list on my behalf (thank you!). > > I got a surgery to one of my kids schedule

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

You rock, Ramy. Seriously, awesome work. -jay On 04/20/2015 01:17 AM, Asselin, Ramy wrote: All Third-Party CI operators: We’ve got 85 Third Party CI systems registered in the wiki[1], all of them running a variety of closed & open-source solutions. Instead of individually maintaining all thos

Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

On 04/20/2015 03:19 AM, Jaume Devesa wrote: > Hi Ramy, > > Soon I'll be the responsible of the Midokura's third-party CI, which has been > mute for a while because a flaky physical resources that our sys admins > couldn't take care because they are overloaded of work... > > Count on me! I do hope

Re: [openstack-dev] [all][code quality] Voting coverage job (-1 if coverage get worse after patch)

On 04/20/2015 07:13 AM, Sean Dague wrote: On 04/18/2015 09:30 PM, Boris Pavlovic wrote: Hi stackers, Code coverage is one of the very important metric of overall code quality especially in case of Python. It's quite important to ensure that code is covered fully with well written unit tests. O

Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring

On 19 April 2015 at 02:23, Jay Pipes wrote: > On 04/13/2015 12:39 PM, Carl Baldwin wrote: > >> On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar >> wrote: >> >>> Hi, >>> >>> I made some investigation on the topic[1] and see several issues on this >>> way. >>> >>> 1. Plugin's create_port() is wrapped

Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0

On 04/20/2015 08:22 AM, Victor Stinner wrote: >> I believe Redhat patch it out. I don't think they should need to, >> since we have explicit knobs for distros to use. > > pbr pulls pip which we don't want in RHEL. Example of patches in RDO: > > https://github.com/redhat-openstack/nova/commit/a199

  1   2   >