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 status of this issue? Is pbr still used/required to get the version of a package a runtime? Yes, a lot. And even worse: in many cases, pbr isn't even declared in the requirements.txt, and I had to double check for the facts myself. I'm not sure that it's an issue in pbr itself. Maybe applications should be fixed instead. The issue is that nobody used oslo.version, and it vanished. Anyway, pbr is actually very small, so I don't think it's an issue. On 04/20/2015 02:22 PM, Victor Stinner wrote: I read somewhere that pkg_resources may also be used to get the version. That's correct, and I don't understand why we're not using that. On 04/20/2015 09:25 PM, Robert Collins wrote: Firstly, pbr has no runtime dep on pip - it doesn't import it. So you don't need pip installed when an installed package uses pbr to get its version. Why does requirements.txt of PBR has pip then? Cheers, Thomas Goirand (zigo) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
On 21 April 2015 at 09:27, Thomas Goirand z...@debian.org 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 and applications to avoid a dependency to pbr at runtime. What's the status of this issue? Is pbr still used/required to get the version of a package a runtime? Yes, a lot. And even worse: in many cases, pbr isn't even declared in the requirements.txt, and I had to double check for the facts myself. I'm not sure that it's an issue in pbr itself. Maybe applications should be fixed instead. The issue is that nobody used oslo.version, and it vanished. Anyway, pbr is actually very small, so I don't think it's an issue. On 04/20/2015 02:22 PM, Victor Stinner wrote: I read somewhere that pkg_resources may also be used to get the version. That's correct, and I don't understand why we're not using that. On 04/20/2015 09:25 PM, Robert Collins wrote: Firstly, pbr has no runtime dep on pip - it doesn't import it. So you don't need pip installed when an installed package uses pbr to get its version. Why does requirements.txt of PBR has pip then? Because if you do 'python setup.py install' in a pbr repo it will *run* pip today to install requirements. But this doesn't apply to packagers, because they will be using the overrides. The packaging of pbr on a distro that doesn't package pip should just ignore that requirement today. In future - 0.12 probably - we'll remove that entry from requirements.txt, but we need to get a release of master done first. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
On Tue, Apr 21, 2015 at 8:38 AM, Fox, Kevin M kevin@pnnl.gov 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 then yum install it... * Horizon UI * Heat Resources. (Some basic stuff like create/delete queue to go along with the stack. also link #1 below) Here you go: https://github.com/openstack/heat/tree/master/contrib/heat_zaqar Horizon has a discovery aspect to it. If users don't know a service is available, its hard for them to use it. Even with the most simple UI of Create/Delete/List queues, discovery is handled. The user knows it exists, and can look for documentation on how to make it work, can ask an admin how to use it, or start poking at the cli for advanced features. Thanks, Kevin 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar -- *From:* Vipul Sabhaya [vip...@gmail.com] *Sent:* Monday, April 20, 2015 1:39 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.gov 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. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Agreed, it’s not an either/or, there is room for both. While Cue could provision Zaqar, it doesn’t make sense, since it is already multi-tenant. As has been said, Cue’s goal is to bring non-multi-tenant message brokers to the cloud. On the question of adoption, what confuses me is why the measurement of success of a project is whether other OpenStack services are integrating or not. Zaqar exposes an API that seems best fit for application workloads running on an OpenStack cloud. The question should be raised to operators as to what’s preventing them from running Zaqar in their public cloud, distro, or whatever. Looking at other services that we consider to be successful, such as Trove, we did not attempt to integrate with other OpenStack projects. Rather, we solved the concerns that operators had. Thanks, Kevin From: Ryan Brown [rybr...@redhat.com] Sent: Monday, April 20, 2015 11:38 AM To: openstack-dev@lists.openstack.org Subject: 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, but could also include rabbit, zmq, etc... If my understanding of the projects is correct, the latter is far more versatile, and more in line with similar openstack approaches like trove. Is there a use case nuance I'm not aware of that warrants duplicating efforts? Because if not, one of the two should be retired and development focused on the other. Note: I do not have a horse in this race. I just feel it's strange that we're building a thing that can be provisioned by the other thing. Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some database) per tenant, where MagnetoDB is one instance (collection of hosts to do database things) that serves many tenants. Cue's goal is I have a not-very-multitenant message bus (rabbit, or whatever) and makes that multitenant by provisioning one per tenant, while Zaqar has a single install (of as many machines as needed) to support messaging for all cloud tenants. This enables great stuff like cross-tenant messaging, better physical resource utilization in sparse-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker approaches don't. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
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 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 then yum install it... * Horizon UI * Heat Resources. (Some basic stuff like create/delete queue to go along with the stack. also link #1 below) Horizon has a discovery aspect to it. If users don't know a service is available, its hard for them to use it. Even with the most simple UI of Create/Delete/List queues, discovery is handled. The user knows it exists, and can look for documentation on how to make it work, can ask an admin how to use it, or start poking at the cli for advanced features. Thanks, Kevin 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar *From:* Vipul Sabhaya [vip...@gmail.com] *Sent:* Monday, April 20, 2015 1:39 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov 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. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Agreed, it’s not an either/or, there is room for both. While Cue could provision Zaqar, it doesn’t make sense, since it is already multi-tenant. As has been said, Cue’s goal is to bring non-multi-tenant message brokers to the cloud. On the question of adoption, what confuses me is why the measurement of success of a project is whether other OpenStack services are integrating or not. Zaqar exposes an API that seems best fit for application workloads running on an OpenStack cloud. The question should be raised to operators as to what’s preventing them from running Zaqar in their public cloud, distro, or whatever. Looking at other services that we consider to be successful, such as Trove, we did not attempt to integrate with other OpenStack projects. Rather, we solved the concerns that operators had. Thanks, Kevin From: Ryan Brown [rybr...@redhat.com mailto:rybr...@redhat.com] Sent: Monday, April 20, 2015 11:38 AM To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: 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, but could also include rabbit, zmq, etc... If my understanding of the projects is correct, the latter is far more versatile, and more in line with similar openstack approaches like trove. Is there a use case nuance I'm not aware of that warrants duplicating efforts? Because if not, one of the two should be retired and development focused on the other. Note: I do not have a horse in this race. I just feel it's strange that we're building a thing that can be provisioned by the other thing. Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some database) per tenant, where MagnetoDB is one instance (collection of hosts to do database things) that serves many tenants. Cue's goal is I have a not-very-multitenant message bus (rabbit, or whatever) and makes that multitenant by provisioning one per tenant, while Zaqar has a single install (of as many machines as needed) to support messaging for all cloud tenants. This enables great stuff like cross-tenant messaging, better physical resource utilization in sparse-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker
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 bo...@pavlovic.me 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 added. It's a huge maintenance burden with very little value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. Let's not mix the bad unit tests in Nova with the fact that code should be fully covered by well written unit tests. This big task can be split into 2 smaller tasks: 1) Bot that will check that we are covering new code by tests and don't introduce regressions http://en.wikipedia.org/wiki/Code_coverage You appear to be talking about statement coverage, which is one of the weaker coverage metrics. if a: thing gets 100% statement coverage if a is true, so I don't need to test when a is false (which would be at a minimum decision coverage). I wonder if the focus is wrong. Maybe helping devs is better than making more gate jobs, for starters; and maybe overall coverage is not a great metric when you're changing 100 lines in 100,000. If you were thinking instead to provide coverage *tools* that were easy for developers to use, that would be a different question. As a dev, I would not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2%, but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it. -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 come up with details tomorrow during our weekly meeting. Thanks, [1] http://goo.gl/Xnw0Cg [2] https://etherpad.openstack.org/p/puppet-bug-triage -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 kevin@pnnl.gov mailto:kevin@pnnl.gov 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 then yum install it... * Horizon UI * Heat Resources. (Some basic stuff like create/delete queue to go along with the stack. also link #1 below) Here you go: https://github.com/openstack/heat/tree/master/contrib/heat_zaqar One thing we need to do in Vancouver is come up with criteria for moving resources from contrib into the main tree. Previously this was whether the project was integrated. As a starter I would suggest something like: 1. project is in the openstack git namespace 2. the client library is synced with global-requirements.txt 3. the resources are complete enough to be useful in template authoring We need to think about potential for integration testing in the gate too. Horizon has a discovery aspect to it. If users don't know a service is available, its hard for them to use it. Even with the most simple UI of Create/Delete/List queues, discovery is handled. The user knows it exists, and can look for documentation on how to make it work, can ask an admin how to use it, or start poking at the cli for advanced features. Thanks, Kevin 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar *From:* Vipul Sabhaya [vip...@gmail.com mailto:vip...@gmail.com] *Sent:* Monday, April 20, 2015 1:39 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.gov mailto:kevin@pnnl.gov 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. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Agreed, it’s not an either/or, there is room for both. While Cue could provision Zaqar, it doesn’t make sense, since it is already multi-tenant. As has been said, Cue’s goal is to bring non-multi-tenant message brokers to the cloud. On the question of adoption, what confuses me is why the measurement of success of a project is whether other OpenStack services are integrating or not. Zaqar exposes an API that seems best fit for application workloads running on an OpenStack cloud. The question should be raised to operators as to what’s preventing them from running Zaqar in their public cloud, distro, or whatever. Looking at other services that we consider to be successful, such as Trove, we did not attempt to integrate with other OpenStack projects. Rather, we solved the concerns that operators had. Thanks, Kevin From: Ryan Brown [rybr...@redhat.com mailto:rybr...@redhat.com] Sent: Monday, April 20, 2015 11:38 AM To: openstack-dev@lists.openstack.org mailto:openstack-dev@lists.openstack.org Subject: 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, but could also include rabbit, zmq, etc... If my understanding of the projects is correct, the latter is far more versatile, and more in line with similar openstack approaches like trove. Is there a use case nuance I'm not aware of that warrants duplicating efforts? Because if not, one of the two should be retired and development focused on the other. Note: I do not have a horse in this race. I just feel it's strange that we're building a thing that can be provisioned by the other thing. Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some
Re: [openstack-dev] [api] Minor changes to API
On 20 April 2015 at 13:02, Kevin L. Mitchell kevin.mitch...@rackspace.com 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 method via **kwargs would start seeing TypeErrors for unexpected arguments. Isn't this what microversions were intended to solve? Yes. I'm relatively recent with OpenStack, so I don't have the history. Did anyone ever consider explicitly allowing new attributes to be added to responses? The problem is advertising that this information is available. There are some cases where that's not necessary: a call returns a JSON dict. If, when the dict does not contain the key, some backward compatible behaviour is assumed, then you are in fact 100% backward compatible. There are other more ambiguous cases, such as setting an attribute that doesn't exist in some cases and getting a failure response; there it's nice to be able to tell in advance via a detection call what to expect. Anyway, I've been bitten by not knowing the unwritten rules so I do agree we could use a policy. That's why, in the past, nova required a new extension even if all you were doing was adding an attribute, and that's why we want a new microversion nowadays. Depends on your project. For Neutron: - some IPv6 changes introduced new (settable) subnet attributes without a bump in version; these were merged in and are now released in Juno - the recent VLAN and MTU changes introduced new network attributes without a bump in version; these were certainly argued about as a break with backward compatibility (and eventually became extensions, though for other reasons than simply that one) - extensions in Neutron can be used to add attributes without changing the core interface; extension detection APIs exist to make planning easier 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 the possible implementations weren't up for (quite so much) debate. For different reasons, Neutron extensions are also not favoured, so there's no clear cut choice to make. -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 kevin.mitch...@rackspace.com 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 method via **kwargs would start seeing TypeErrors for unexpected arguments. Isn't this what microversions were intended to solve? Yes. I'm relatively recent with OpenStack, so I don't have the history. Did anyone ever consider explicitly allowing new attributes to be added to responses? The problem is advertising that this information is available. There are some cases where that's not necessary: a call returns a JSON dict. If, when the dict does not contain the key, some backward compatible behaviour is assumed, then you are in fact 100% backward compatible. There are other more ambiguous cases, such as setting an attribute that doesn't exist in some cases and getting a failure response; there it's nice to be able to tell in advance via a detection call what to expect. Anyway, I've been bitten by not knowing the unwritten rules so I do agree we could use a policy. That's why, in the past, nova required a new extension even if all you were doing was adding an attribute, and that's why we want a new microversion nowadays. Depends on your project. For Neutron: - some IPv6 changes introduced new (settable) subnet attributes without a bump in version; these were merged in and are now released in Juno - the recent VLAN and MTU changes introduced new network attributes without a bump in version; these were certainly argued about as a break with backward compatibility (and eventually became extensions, though for other reasons than simply that one) - extensions in Neutron can be used to add attributes without changing the core interface; extension detection APIs exist to make planning easier 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 the possible implementations weren't up for (quite so much) debate. For different reasons, Neutron extensions are also not favoured, so there's no clear cut choice to make. Uhm, there is: https://wiki.openstack.org/wiki/APIChangeGuidelines and if you read that adding attrs without advertising it (using an extension, microversion, or whatever) is not an allowed change. Just adding things without a new extension or microversion makes the end user story terrible because it puts the burden completely on the user to try and figure out which version 2 (or whatever it currently is marked as) of the api the cloud they're using speaks. Think about it if it were a library, that just started adding things to it's interfaces without bumping any version. Even if it was a backwards compatible addition you would still expect the version to increment to indicate that the new stuff was there and available for use. -Matt Treinish pgpgK3_wSwOQj.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 into these kind of github.com interconnects (for lack of better words) somehow, but I'm not sure if any such interconnect exists (something that translates gerrit reviews into a format these systems can understand and post back to?). Ian Wells wrote: On 20 April 2015 at 07:40, Boris Pavlovic bo...@pavlovic.me mailto:bo...@pavlovic.me 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 added. It's a huge maintenance burden with very little value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. Let's not mix the bad unit tests in Nova with the fact that code should be fully covered by well written unit tests. This big task can be split into 2 smaller tasks: 1) Bot that will check that we are covering new code by tests and don't introduce regressions http://en.wikipedia.org/wiki/Code_coverage You appear to be talking about statement coverage, which is one of the weaker coverage metrics. if a: thing gets 100% statement coverage if a is true, so I don't need to test when a is false (which would be at a minimum decision coverage). I wonder if the focus is wrong. Maybe helping devs is better than making more gate jobs, for starters; and maybe overall coverage is not a great metric when you're changing 100 lines in 100,000. If you were thinking instead to provide coverage *tools* that were easy for developers to use, that would be a different question. As a dev, I would not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2%, but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it. -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 'utf8_general_ci' ? I've seen it's less accurate at sorting, but faster. Please tell me if I'm wrong and if we can already change it somewhere in configuration. If you are interested by my exact context, it affects our Puppet modules: https://bugs.launchpad.net/puppet-glance/+bug/1446375 Thank you, -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 up an environment which behaves like a baremetal env[2] I'd like to build on this to create a new upstream repo aimed at setting up an environment which is ready for undercloud and overcloud installation. For rdo-management, using it would be documented in its own section of the Setup chapter[3] Ben's heat templates bring up BMC and baremetal nodes. I've been extending those to also define the undercloud network and a bare undercloud node ready for undercloud installation (or optionally an image-based undercloud). Another future enhancement could be to figure out how to use only a single nova server serve all of the BMC requests (possibly with one server having a neutron port per baremetal it is managing) This will still require patching the nethercloud until we can find a way of upstreaming those changes. The repo can at least be where those patches live for now. So my questions for now would be: What should the repo be called? quintuplo-setup? Where should it live? git openstack in the openstack namespace? github rdo-management? [1] http://blog.nemebean.com/tags/quintupleo [2] https://github.com/cybertron/tripleo-scripts [3] https://repos.fedorapeople.org/repos/openstack-m/instack-undercloud/html/setup.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 - we'll be pulling from the that to select talks. Brisbane is a beautiful city, the venue is great - and so is the weather. If you've any questions about whether to submit or not, please ping me or Joshua Hesketh - we're organising the miniconf together and can provide guidance. Cheers, Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2% It is not the goal of the job that I add. Job checks that your patch don't introduce code that is not covered by unit test (that is all). but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it. And this is exactly what tox -e cover does and job that run tox -e cover in gates. Best regards, Boris Pavlovic On Tue, Apr 21, 2015 at 3:28 AM, Ian Wells ijw.ubu...@cack.org.uk wrote: On 20 April 2015 at 07:40, Boris Pavlovic bo...@pavlovic.me 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 added. It's a huge maintenance burden with very little value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. Let's not mix the bad unit tests in Nova with the fact that code should be fully covered by well written unit tests. This big task can be split into 2 smaller tasks: 1) Bot that will check that we are covering new code by tests and don't introduce regressions http://en.wikipedia.org/wiki/Code_coverage You appear to be talking about statement coverage, which is one of the weaker coverage metrics. if a: thing gets 100% statement coverage if a is true, so I don't need to test when a is false (which would be at a minimum decision coverage). I wonder if the focus is wrong. Maybe helping devs is better than making more gate jobs, for starters; and maybe overall coverage is not a great metric when you're changing 100 lines in 100,000. If you were thinking instead to provide coverage *tools* that were easy for developers to use, that would be a different question. As a dev, I would not be terribly interested in finding that I've improved overall test coverage from 90.1% to 90.2%, but I might be *very* interested to know that I got 100% decision (or even boolean) coverage on the specific lines of the feature I just added by running just the unit tests that exercise it. -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?)
On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.gov 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. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Agreed, it’s not an either/or, there is room for both. While Cue could provision Zaqar, it doesn’t make sense, since it is already multi-tenant. As has been said, Cue’s goal is to bring non-multi-tenant message brokers to the cloud. On the question of adoption, what confuses me is why the measurement of success of a project is whether other OpenStack services are integrating or not. Zaqar exposes an API that seems best fit for application workloads running on an OpenStack cloud. The question should be raised to operators as to what’s preventing them from running Zaqar in their public cloud, distro, or whatever. Looking at other services that we consider to be successful, such as Trove, we did not attempt to integrate with other OpenStack projects. Rather, we solved the concerns that operators had. Thanks, Kevin From: Ryan Brown [rybr...@redhat.com] Sent: Monday, April 20, 2015 11:38 AM To: openstack-dev@lists.openstack.org Subject: 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, but could also include rabbit, zmq, etc... If my understanding of the projects is correct, the latter is far more versatile, and more in line with similar openstack approaches like trove. Is there a use case nuance I'm not aware of that warrants duplicating efforts? Because if not, one of the two should be retired and development focused on the other. Note: I do not have a horse in this race. I just feel it's strange that we're building a thing that can be provisioned by the other thing. Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some database) per tenant, where MagnetoDB is one instance (collection of hosts to do database things) that serves many tenants. Cue's goal is I have a not-very-multitenant message bus (rabbit, or whatever) and makes that multitenant by provisioning one per tenant, while Zaqar has a single install (of as many machines as needed) to support messaging for all cloud tenants. This enables great stuff like cross-tenant messaging, better physical resource utilization in sparse-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker approaches don't. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty
On 20 April 2015 at 04:54, Morgan Fainberg morgan.fainb...@gmail.com 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 when we feel like it we will be doing a standard mile-stone tag for (example) L1, L2, L3, and Liberty final. We will then maintain the backport for stable/Liberty for the life of the release. I'm confused ;). In a couple of ways. Firstly, gloal-requirements and release-schedule are two different dimensions. They connect in that some changes to global-requirements are coordinated with the 6-month release schedule, but its a fairly open relation: you can release whenever you like (like Swift does) and still coordinate with global-requirements. Secondly, how will e.g. nova depend on new functionality in keystonemiddleware? I presume you'll make nova depend on the L1 release after its done, and block consuming the new functionality until the middleware has released? ... Today middleware is released independent of everything (like a client) but since it is tightly coupled to a set of requirements using 1.5.x with Juno is challenging, since there is a requirements mismatch. Today the only way you know what versions work is by either looking at release dates or by trial/error (or examining requirements). I think it is far better to release middleware like a server project to more clearly indicate release schedule and compatibility. Whats the coupling there? More specifically, is it 'the middleware needs other components that don't have stable APIs' or, as I suspect,is it really https://github.com/pypa/pip/issues/988 (and associated glitches) - which I'm fixing as we speak... Generally in dependency relationships semver should be enough: I'm very worried that you seem to be saying that semver *does not* work here, and I want to understand the details (independent of whatever keystonemiddleware does), so that work on pbr and other parts of our release process is fully informed. Knowing that 1.3.x receives backports (and tied to Juno), but 1.4.x doesn't because it was released between Juno and kilo, and 1.5.x does again (and is tied to kilo) is just a poor experience for our deployers. I don't want to have to name some release LTS of keystonemiddleware, let's release in a way that make sense for how it is used. But all three are compatible based on their version: anything that worked with 1.3 should work with 1.5. Why doesn't it? Details of the version numbers will be hashed out at the summit and the release management team. (E.g do we move to a 2015.x.x model? Do we increment the X per release in semver, or the 'y'?) This part is not yet determined and requires some discussion. Indeed. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 zuul framework. Zuul was still under discussion at the time when we put together our CI. We use Jenkins as front end, along with Gerrit triggers, and AWS for posting/preserving results/log. We have dedicated back-end servers for testing. My paranoia at this point will be to learn a new framework, risk breaking things and taking a huge effort to get things stabilized - without much additional ROI. Am I overreacting here or does my argument makes sense? I wonder how many folks will be in that camp? Sukhdev On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy ramy.asse...@hp.com 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 those similar solutions, let’s join together and collectively maintain a single solution. If that sounds good to you, there’s an Infra-spec that’s been approved [2] to refactor much of what the Infrastructure team uses for the upstream “Jenkins” CI to be more easily reusable by many of us. We’ve got stories defined [3], and a few patches submitted. We’re using the gerrit-topic “downstream-puppet” [4]. For example, we’ve got the first part under review for the “Log Server”, which creates your own version of http://logs.openstack.org/ If anyone is interested in migrating towards a common solution, reply, or ping me IRC (asselin) on Freenode #openstack-infra, or join some of the third party ci meetings [5]. Thanks! Ramy [1] https://wiki.openstack.org/wiki/ThirdPartySystems [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [3] https://storyboard.openstack.org/#!/story/2000101 [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z [5] https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 actually perform its load balancing tasks. It has a devstack plugin that works well, all I need to do is add the appropriate enable_plugin and enable_service lines to my local.conf and the plugin code sets up everything nicely. So far so good. Octavia is a reference implementation (currently in stackforge) that will plug in to neutron-lbaas and provide scalable, HA-capable load balancing agents above and beyond the default implementation. I have also written a devstack plugin for Octavia, and it also works reasonably well (I still need to finish up a few loose ends in it). That plugin works well too, by adding the appropriate enable_plugin and enable_service entries to local.conf. So adding this: enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_plugin octavia https://git.openstack.org/stackforge/octavia enable_service q-lbaasv2 enable_service octavia enable_service o-cw enable_service o-hk enable_service o-hw to my local.conf results in a working lbaasv2/Octavia devstack. Now what I would like to do is automate as much of this Octavia-specific information as possible in neutron-lbaas. In principle, if I could specify enable_plugin neutron-lbaas https://git.openstack.org/openstack/neutron-lbaas enable_service q-lbaasv2 enable_service octavia All there remaining knowledge could be written into neutron-lbaas/devstack. So I tried this, and added code to the neutron-lbaas plugin.sh that enabled the Octavia plugin and services. I have tried running enable_plugin octavia from various points in the neutron_lbaas/devstack/plugin.sh, but it appears that by the time we begin loading plugins it is too late to be doing this. Does this seem like something that could be made to work, or does it sound too fragile, dangerous, etc? I would appreciate any comments. Thanks, Al __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api] Minor changes to API
On 20 April 2015 at 15:23, Matthew Treinish mtrein...@kortar.org 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 the possible implementations weren't up for (quite so much) debate. For different reasons, Neutron extensions are also not favoured, so there's no clear cut choice to make. Uhm, there is: https://wiki.openstack.org/wiki/APIChangeGuidelines and if you read that adding attrs without advertising it (using an extension, microversion, or whatever) is not an allowed change. It is also not an unallowed change (given that there's a section that appears to define what an unallowed attribute change is). The page reads very awkwardly. Whatever your preference might be, I think it's best we lose the ambiguity. And perhaps advertise that page a little more widely, actually - I hadn't come across it in my travels. And perhaps improve its air of authority: rules on this subject should probably live somewhere in a repo so that it's clear there's consensus for changes. Currently anyone can change it for any reason, and two years after the last substantive change it's hard to say who even knew it was being changed, let alone whether they agreed. Just adding things without a new extension or microversion makes the end user story terrible because it puts the burden completely on the user to try and figure out which version 2 (or whatever it currently is marked as) of the api the cloud they're using speaks. Think about it if it were a library, that just started adding things to it's interfaces without bumping any version. Even if it was a backwards compatible addition you would still expect the version to increment to indicate that the new stuff was there and available for use. I appreciate your point and I'd be happy for that to be more obviously our position. The issue that the MTU change hit was the conflict between this general principle and the consensus in its project. Neutron's core team was giving a strong 'no more extensions' vibe at the last summit, Neutron hasn't got microversioning, and the content of that document is two years old and apparently not very widely known by reviewers as well as me. No choice would have been right. So again, how about we fix that document up and put it somewhere where it receives a bit more control and attention? -- Ian. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 emil...@redhat.com wrote: 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 come up with details tomorrow during our weekly meeting. Thanks, [1] http://goo.gl/Xnw0Cg [2] https://etherpad.openstack.org/p/puppet-bug-triage -- Emilien Macchi -- To unsubscribe from this group and stop receiving emails from it, send an email to puppet-openstack+unsubscr...@puppetlabs.com. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 basic stuff like create/delete queue to go along with the stack. also link #1 below) Horizon has a discovery aspect to it. If users don't know a service is available, its hard for them to use it. Even with the most simple UI of Create/Delete/List queues, discovery is handled. The user knows it exists, and can look for documentation on how to make it work, can ask an admin how to use it, or start poking at the cli for advanced features. Thanks, Kevin 1. https://blueprints.launchpad.net/heat/+spec/software-config-zaqar From: Vipul Sabhaya [vip...@gmail.com] Sent: Monday, April 20, 2015 1:39 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) On Mon, Apr 20, 2015 at 12:07 PM, Fox, Kevin M kevin@pnnl.govmailto:kevin@pnnl.gov 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. Cue is a multitenant api to provision non multitenant queues. Zaqar is an api for a multitenant queueing system. They are complimentary services. Agreed, it’s not an either/or, there is room for both. While Cue could provision Zaqar, it doesn’t make sense, since it is already multi-tenant. As has been said, Cue’s goal is to bring non-multi-tenant message brokers to the cloud. On the question of adoption, what confuses me is why the measurement of success of a project is whether other OpenStack services are integrating or not. Zaqar exposes an API that seems best fit for application workloads running on an OpenStack cloud. The question should be raised to operators as to what’s preventing them from running Zaqar in their public cloud, distro, or whatever. Looking at other services that we consider to be successful, such as Trove, we did not attempt to integrate with other OpenStack projects. Rather, we solved the concerns that operators had. Thanks, Kevin From: Ryan Brown [rybr...@redhat.commailto:rybr...@redhat.com] Sent: Monday, April 20, 2015 11:38 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: 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, but could also include rabbit, zmq, etc... If my understanding of the projects is correct, the latter is far more versatile, and more in line with similar openstack approaches like trove. Is there a use case nuance I'm not aware of that warrants duplicating efforts? Because if not, one of the two should be retired and development focused on the other. Note: I do not have a horse in this race. I just feel it's strange that we're building a thing that can be provisioned by the other thing. Well, with Trove you can provision databases, but the MagnetoDB project still provides functionality that trove won't. The Trove : MagnetoDB and Cue : Zaqar comparison fits well. Trove provisions one instance of X (some database) per tenant, where MagnetoDB is one instance (collection of hosts to do database things) that serves many tenants. Cue's goal is I have a not-very-multitenant message bus (rabbit, or whatever) and makes that multitenant by provisioning one per tenant, while Zaqar has a single install (of as many machines as needed) to support messaging for all cloud tenants. This enables great stuff like cross-tenant messaging, better physical resource utilization in sparse-tenant cases, etc. As someone who wants to adopt Zaqar, I'd really like to see it continue as a project because it provides things other message broker approaches don't. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [heat] is cloudwatch really deprecated?
On Tue, Apr 21, 2015 at 12:33 PM, x Lyn xuanlangj...@gmail.com 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 Zane Bitter zbit...@redhat.com: On 17/04/15 13:54, Matt Fischer wrote: On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter zbit...@redhat.com mailto:zbit...@redhat.com wrote: On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: This feature will be deprecated or removed during the Havana cycle as we move to using Ceilometer as a metric/alarm service instead. [1] However it seems that cloudwatch is still being developed. It doesn't seem that way to me, and without at least some kind of hint I'm not in a position to speculate on why it might seem that way to you. So is it deprecated or not? Yes, it's very deprecated. In fact, we should go ahead and disable it in the default config. - ZB I was just looking at the dates in the commit log for the cloudwatch folder and seeing things from 2015. If it's truly deprecated, that's great, I'll remove it from my environment. OK, that's what I looked at too, and there were a lot of recent changes but they all appeared to be global cleanups that went across the whole Heat codebase. The last thing that looked like active development was in July 2013. You definitely won't regret removing it ;) So before we get too excited, ceilometer AFAIK does not have a native guest client that doesn't use a token. ATM heat-api-cw bounces metrics to ceilometer that were associated with ceilometer alarms. -Angus cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 change was send before the project-config change went in -
and AFAIK our scripts only change to in progress on the *first* change.
But once your patch merges, it should close it nevertheless,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 zbit...@redhat.com: On 17/04/15 13:54, Matt Fischer wrote: On Fri, Apr 17, 2015 at 11:03 AM, Zane Bitter zbit...@redhat.com mailto:zbit...@redhat.com wrote: On 17/04/15 12:46, Matt Fischer wrote: The wiki for Using Cloudwatch states: This feature will be deprecated or removed during the Havana cycle as we move to using Ceilometer as a metric/alarm service instead. [1] However it seems that cloudwatch is still being developed. It doesn't seem that way to me, and without at least some kind of hint I'm not in a position to speculate on why it might seem that way to you. So is it deprecated or not? Yes, it's very deprecated. In fact, we should go ahead and disable it in the default config. - ZB I was just looking at the dates in the commit log for the cloudwatch folder and seeing things from 2015. If it's truly deprecated, that's great, I'll remove it from my environment. OK, that's what I looked at too, and there were a lot of recent changes but they all appeared to be global cleanups that went across the whole Heat codebase. The last thing that looked like active development was in July 2013. You definitely won't regret removing it ;) cheers, Zane. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 madhuri.ra...@gmail.com wrote: 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 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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. 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/168424/ https://review.openstack.org/#/c/168419/ https://review.openstack.org/#/c/175247/ https://review.openstack.org/#/c/175077/ https://review.openstack.org/#/c/163706/ I would like to kindly request you and the core team to get the Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base. If there is anything else you need from the CI and the driver, please do let me know. Thank you, Diem. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April 23rd Hello Folks, I would like to invite all available contributors to help us to complete the OpenStack Networking Guide. We are having a Networking Doc Day on April 23rd in order to review the current guide and make a big push on its content. Let's use both the Neutron and Docs IRC channels: #openstack-neutron #openstack-doc All the expected content is being described in the TOC: https://wiki.openstack.org/wiki/NetworkingGuide/TOC Information for Doc contributors in here: https://wiki.openstack.org/wiki/Documentation/HowTo#Edit_OpenStack_RST_and.2For_DocBook_documentation We have prepared an etherpad to coordinate who is doing what: https://etherpad.openstack.org/p/networking-guide There are so many ways you can contribute: * Assign to yourself one of the available chapters * Review the current content and open bugs if needed * Review the existing gerrit commit if you are familiar with the information * Be available on IRC to answer some questions about configuration details or functionality * Cheering at the contributors! Do not hesitate in contacting me for any questions. Cheers! Edgar Magana IRC: emagana emag...@gmail.commailto:emag...@gmail.com edgar.mag...@workday.commailto:edgar.mag...@workday.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.org/#/c/175294/)
Send a patch for project-config repo, file gerrit/projects.yaml and add to
your project:
groups:
python-rack
Thanks.
2015-04-20 16:56 GMT+09:00 Kaneko Takehiro myphone...@gmail.com:
Andreas,
I missed it.
Thanks for your help.
Takehiro
2015-04-20 16:40 GMT+09:00 Andreas Jaeger a...@suse.com:
On 04/20/2015 09:26 AM, Kaneko Takehiro wrote:
Hi,
I'm managing a stackforge project and want to integrate Gerrit with
Launchpad.
Links;
Git: https://git.openstack.org/cgit/stackforge/rack/
Launchpad: https://launchpad.net/python-rack
Project name 'rack' is duplicated in Launchpad so I named our project
'python-rack'.
How can I integrate Gerrit with Launchpad in this case?
Send a patch for project-config repo, file gerrit/projects.yaml and add
to your project:
groups:
python-rack
Btw. this is documented in our infra manual:
http://docs.openstack.org/infra/manual/creators.html#add-the-project-to-the-master-project-list
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 duncan.tho...@gmail.com 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/show/204933/ (generated with https://github.com/jogo/lastcomment) On 20 April 2015 at 20:47, Diem Tran diem.t...@oracle.com wrote: 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/168424/ https://review.openstack.org/#/c/168419/ https://review.openstack.org/#/c/175247/ https://review.openstack.org/#/c/175077/ https://review.openstack.org/#/c/163706/ I would like to kindly request you and the core team to get the Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base. If there is anything else you need from the CI and the driver, please do let me know. Thank you, Diem. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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: 649 Missing lines in proposed change : 669 NameStmts Miss Branch BrMiss Cover @@ -43 +43 @@ -rally/benchmark/processing/utils 52 0 30 198.780% +rally/benchmark/processing/utils 52 20 30 1557.317% @@ -190 +190 @@ -TOTAL9400649 228439491.073% +TOTAL9400669 228440890.782% Please write more unit tests, we should keep our test coverage :( Best regards, Boris Pavlovic On Mon, Apr 20, 2015 at 9:11 PM, Hayes, Graham graham.ha...@hp.com wrote: 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 with well written unit tests. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1) 9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 The link to the important line was key, because without it, just clicking through from the review was incomprehensible to me. Can I suggest some whitespace or bordering so we can see where the error is easily? 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 pointer to how things probably should be, but sometimes it's entirely o-k to regress this number a few points. Also graphing this over time in a post-commit job seems like a no-brainer. Designate has started doing this - it is still a WIP as we continue tweaking settings, but we have a dashboard here - http://sonar.designate-ci.com/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 diem.t...@oracle.com wrote: 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/168424/ https://review.openstack.org/#/c/168419/ https://review.openstack.org/#/c/175247/ https://review.openstack.org/#/c/175077/ https://review.openstack.org/#/c/163706/ I would like to kindly request you and the core team to get the Oracle ZFSSA iSCSI driver re-integrated back to the Cinder code base. If there is anything else you need from the CI and the driver, please do let me know. Thank you, Diem. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 compatibility concerns, meaning we need to expose some more symbols as part of public API for the library to facilitate neutron switch to it. === oslo.policy was graduated during Kilo [1]. Neutron considered the switch to it [2], but failed to achieve it because some library symbols that were originally public (or at least looked like public) in policy.py from oslo-incubator, became private in oslo.policy. Specifically, Neutron policy code [3] relies on the following symbols that are now hidden inside oslo_policy._checks (note the underscore in the name of the module that suggests we cannot use the module directly): - - RoleCheck - - RuleCheck - - AndCheck Those symbols are used for the following matters: (all the relevant neutron code is in neutron/policy.py) 1. debug logging in case policy does not authorize an action (RuleCheck, AndCheck) [log_rule_list] 2. filling in admin context with admin roles (RoleCheck, RuleCheck, AndCheck/OrCheck internals) [get_admin_roles] 3. aggregating core, attribute and subattribute policies (RuleCheck, AndCheck) [_prepare_check] If we make the checks public, is that sufficient? I have no problem with most of these being public. The only one that is Keystone specific is the Role check, which I would like to rework. Instead of RoleCheck, can you build on top of the newly submitted ability to do List checks? https://review.openstack.org/#/c/169045/3/oslo_policy/_checks.py,cm Rule, And, Or, Not and Generic checks are building blocks for other logic, and should be public. == 1. debug logging in case policy does not authorize an action == Neutron logs rules that failed to match if policy module does not authorize an action. Not sure whether Neutron developers really want to have those debug logs, and whether we cannot just kill them to avoid this specific usage of private symbols; though it also seems that we could easily use __str__ that is present for all types of Checks instead. So it does not look like a blocker for the switch. == 2. filling in admin context with admin roles == Admin context object is filled with .roles attribute that is a list of roles considered granting admin permissions [4]. The attribute would then be used by plugins that would like to do explicit policy checks. As per Salvatore, this attribute can probably be dropped now that all plugins and services don't rely on it (Salvatore mentioned lbaas mixins as the ones that previously relied on it, but are now not doing it since service split from neutron tree (?)). The problem with dropping the .roles attribute from context object in Liberty is that we, as a responsible upstream with lots of plugins maintained out-of-tree (see the ongoing vendor decomposition effort) would need to support the attribute while it's marked as deprecated for at least one cycle, meaning that if we don't get those oslo.policy internals we rely on in Liberty, we would need to postpone the switch till Mizzle, or rely on private symbols during the switch (while a new release of oslo.policy can easily break us). (BTW the code to extract admin roles is not really robust and has bugs, f.e. it does not handle AndChecks that could be used in context_is_admin. In theory, 'and' syntax would mean that both roles are needed to claim someone is an admin, while the code to extract admin roles handles 'and' the same way as 'or'. For the deprecation time being, we may need to document this limitation.) == 3. aggregating core, attribute and subattribute policies == That's the most interesting issue. For oslo.policy, policies are described as target: rule, where rule is interpreted as per registered checks, while target is opaque to the library. Neutron extended the syntax for target as: target[:attribute[:subattribute]]. If attribute is present in a policy entry, it applies to target iff attribute is set, and 'enforce_policy' is set in attribute map for the attribute in question, and target is not read-only (=its name does not start from get_). If subattribute is present, the rule applies to target if 'validate' is set in attribute map for the attribute, and its type is dict, plus all the requirements for :attribute described above. Note that those rules are *aggregated* into single matching rule with AndCheck, so f.e. if action is create_network, and provider is set in target, then the actual rule validated would be all the rules for create_network, create_network:provider, and e.g. create_network:provider:physical_network, joined into single rule with AndCheck (meaning, target should conform to all of those requirements). This stands for a significant extension of original oslo.policy intent. Originally, I thought
Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty
On 21 April 2015 at 03:24, Sean Dague s...@dague.net 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 reason I ask about releases, is that I'd like to keep the upstream gating release based (so it would consume the milestones) and not git HEAD based, because otherwise we're requiring code from an unreleased library, which lead us into some weird places. Yes, that was exactly my concern. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated
Awesome, thanks Josh. On 04/20/2015 07:14 AM, Joshua Hesketh wrote: Hi Sean, Thanks for your work on this. I'll take a closer look tomorrow and remove the downgrade testing from turbo-hipster in line with the TC decision. Cheers, Josh From: Sean Dague s...@dague.net Sent: Monday, 20 April 2015 8:38 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated This proposed patch to drop the db downgrades in Nova master is making Turbo Hipster face plant - https://review.openstack.org/#/c/175010/ It appears that turbo hipster is walking all the way up, then walking back down through migrations, which clearly, is no longer a thing. It would be nice to merge this patch sooner rather than later, so would be great if Turbo hipster could function on migrations without downgrades RSN. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 those similar solutions, let’s join together and collectively maintain a single solution. If that sounds good to you, there’s an Infra-spec that’s been approved [2] to refactor much of what the Infrastructure team uses for the upstream “Jenkins” CI to be more easily reusable by many of us. We’ve got stories defined [3], and a few patches submitted. We’re using the gerrit-topic “downstream-puppet” [4]. For example, we’ve got the first part under review for the “Log Server”, which creates your own version of http://logs.openstack.org/ If anyone is interested in migrating towards a common solution, reply, or ping me IRC (asselin) on Freenode #openstack-infra, or join some of the third party ci meetings [5]. Thanks! Ramy [1] https://wiki.openstack.org/wiki/ThirdPartySystems [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [3] https://storyboard.openstack.org/#!/story/2000101 [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z [5] https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 scheduled on Wednesday (it’s something very mild near the ear), also it’s holiday for a few of the participants that were intending to join. I hope your kid (and you) will be well. I hope it works for most of you, otherwise we will all be available on next Wednesday 29th as planned. Note that the proposed time conflicts with general neutron meeting. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNQK/AAoJEC5aWaUY1u578PcIAL7FkO+wSV4AdkcjIrFNbrcX aHmbV9pYYkUf3GTrBfqBzJ37XqApSCrFinZPpg7vrDfp1TLxvWXBoh8HhBrJUiv3 ItqEGpixotKcuT06E0QSm76p6ZkIFffy68Iudj1dX1bLVuDa7VU59jcBxo9H3EMQ Ei4Vtvf3M1a8wPZV+FHcySzkjrLNJNlgUCHOy/h5JCWC26nGxKHciFYxXz82HQpQ V6o2d+tyLAkJnkIkmbUuRfOLoZaBFwc7ortS1CEt00fMux6EyoNmuhouBZxoUp84 IKZsSDea8QRciHFot1mUA4cF9Up1vFiNuy9K3FOh8VuNCxzc2Un0sGtjIP6zdb0= =Poy8 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral] Mistral Kilo RC1 released!
Hi all, Another milestone of Mistral (Kilo RC1) is released! Below are the links to Mistral and Mistral Client release pages where you can find downloadables and info about fixed bugs. Mistral: https://launchpad.net/mistral/kilo/kilo-rc1 https://launchpad.net/mistral/kilo/kilo-rc1 Mistral Client: https://launchpad.net/python-mistralclient/kilo/kilo-rc1 https://launchpad.net/python-mistralclient/kilo/kilo-rc1 Thanks Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/20/2015 02:22 PM, 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/a19939c8f9a7b84b8a4d71 3fe3d26949e5664089 https://github.com/redhat-openstack/python-keystoneclient/commit/e02d529 a87aef8aaca0616c8ee81de224bf1f52a https://github.com/redhat-openstack/neutron/commit/85302b75362df302703 83e3a373e60e81b1b2384 (well, it's always the same change) AFAIK Delorean (aka RDO/master) stopped doing it. The approach remains for RHEL-OSP to avoid python-pbr (and python-pip) dependencies. That said, I am not sure we should do it in RHEL-OSP too. If RHEL does not want to see python-pip in their repos, then RHEL-OSP could ship it with its repositories (?). I think you should reach Alan Pevec on the matter since he is involved in pbr cleanup. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNPOfAAoJEC5aWaUY1u57HqUIALdQ+GsUQA9Nc+0nLuUBLM49 nOQtsIqp8giNfO2o897ll1uM93VD4io5fLXaNrp6K7jKba6e6bjlCRPjybuwbAQD gNrfZzB4ZAUMVDj4o4Ftl/kwnS1ijx1EoRV/D7YWgzU0VF//qVyBHxZNv8+TdV/U pF/ij5ZJi5TdnBO8QpIo91GmEFvR0ibhWNxCoEbOjdpSDcHUtfYNqR3pX/8mGk4d tGn3hN1mijvUPgcnHfv9aoh4KAti6sGMcVHgFZ4lq1ihvoRGUCOfh9tPGeZwqcrj K+znsfsZC6sq11h4pZUZ6ZZ3QKqyCJ/xLxuR23ThnXKi3mzQG99rhnRvoxTdOPc= =7WTq -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [mistral] Mistral team meeting reminder - 04/20/2015
This is a reminder about a team meeting today that we’ll hold at #openstack-mistral at 16.20 UTC. Agenda: Review action items Current status (progress, issues, roadblocks, further plans) What's left to do in Kilo? (critical bugs, docs etc.) Open discussion [0] https://wiki.openstack.org/wiki/Meetings/MistralAgenda https://wiki.openstack.org/wiki/Meetings/MistralAgenda Renat Akhmerov @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
I don't think its a bug in the applications. swift gets its version using pkg_resources, or falls back to pbr: https://github.com/openstack/swift/blob/master/swift/__init__.py I mean that other applications may do something similar? Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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/a19939c8f9a7b84b8a4d713fe3d26949e5664089
https://github.com/redhat-openstack/python-keystoneclient/commit/e02d529a87aef8aaca0616c8ee81de224bf1f52a
https://github.com/redhat-openstack/neutron/commit/85302b75362df30270383e3a373e60e81b1b2384
(well, it's always the same change)
Can't we enhance pbr to build (source/wheel) distributions of applications
which don't depend on pbr? Basically implement these patches in pbr?
I read somewhere that pkg_resources may also be used to get the version.
You're absolutely correct, here's a quick snippet to get the version as
a string:
import pkg_resources
pkg_resources.get_distribution('nova').version
Where, of course, s/nova/any-package-name/
--
Ryan Brown / Software Engineer, Openstack / Red Hat, Inc.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 luqas will still be available some times, he has been so proactive. It has been wonderful to work with him. I'm looking forward to getting to know you as well, Jaume. Thanks Asselin, for kicking off this thread, you have been doing wonderful work here. It is great to see you have reached this place. I am really looking forward to your work continuing, making installing and maintaining a ci easier for both operators and for infra. Thank you, Anita. On Mon, 20 Apr 2015 05:17, 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 those similar solutions, let’s join together and collectively maintain a single solution. If that sounds good to you, there’s an Infra-spec that’s been approved [2] to refactor much of what the Infrastructure team uses for the upstream “Jenkins” CI to be more easily reusable by many of us. We’ve got stories defined [3], and a few patches submitted. We’re using the gerrit-topic “downstream-puppet” [4]. For example, we’ve got the first part under review for the “Log Server”, which creates your own version of http://logs.openstack.org/ If anyone is interested in migrating towards a common solution, reply, or ping me IRC (asselin) on Freenode #openstack-infra, or join some of the third party ci meetings [5]. Thanks! Ramy [1] https://wiki.openstack.org/wiki/ThirdPartySystems [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [3] https://storyboard.openstack.org/#!/story/2000101 [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z [5] https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][L3] IPAM alternate refactoring
On 19 April 2015 at 02:23, Jay Pipes jaypi...@gmail.com wrote: On 04/13/2015 12:39 PM, Carl Baldwin wrote: On Mon, Apr 13, 2015 at 8:44 AM, Pavel Bondar pbon...@infoblox.com wrote: Hi, I made some investigation on the topic[1] and see several issues on this way. 1. Plugin's create_port() is wrapped up in top level transaction for create floating ip case[2], so it becomes more complicated to do IPAM calls outside main db transaction. Is it time to look at breaking the bond between a floating and a port? IMO, yes. I already expressed my opinion on the matter in [1]. But I think you should stay focused on a viable strategy for taking IPAM out of db_base_plugin_v2 and not make this another gargantuan task. I think the only reason that a port is created to back a floating IP is for IPAM because IP addresses are only reserved by creating a port with it. I'm sure this won't be very easy but I think it is worth a look to see what will be involved. Why can't port creation be done entirely separately from assigning some *thing* -- i.e. a floating IP -- to that port? The creation of a port can be done in a separate DB transaction. Assignment of said port ID to a floating IP resource can be done in a separate DB transaction (or external IPAM system call). The current logic makes non trivial to split transactions for port and floating IP creation. Since at the end of day I hope we'll converge to a consensus where that port isn't needed, I hope it will be not too difficult to do the IPAM transactions separately and then pass to the operation which creates the floating IP the IP address which was allocated for it on the external network. Trying to trace the DB transaction scope through all the mess of mixin classes in Neutron is, well, extremely mind-boggling. It is actually not that mind blogging... in general every method corresponds to a single ginormous transaction without savepoints. What is mindbloggin is following the evolution of said transaction across mixings and understanding the myriad of point where it can abort. Best, -jay [1] http://lists.openstack.org/pipermail/openstack-dev/2014-January/024323.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1) 9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 Honestly, I'm suspicious of approaches like this. While 90% coverage is clearly better than 0% coverage, it's not clear that 91% coverage is always better than 90% coverage. Especially when you talk about larger and more complex code bases. Well, I think there are very few cases where *less* coverage is better. I actually firmly feel that #3 is wrong. I think it's a lot better to have an early conversation with people about unit tests that need to be written when they don't submit any. Because I think it's a lot less friendly to have someone iterate 10 patches to figure out how to pass a bot's idea of good tests, and then have a reviewer say it's wrong. This I completely agree with. Asking for unit tests is a common thing, and if done early in the review process, is not a non-friendly thing. It's just matter of fact. And if the comment is given with some example unit test code -- or a pointer to a unit test that could be used as an example -- even better. It grows the submitter. Honestly, coverage for projects seems to me to be more of an analog measure that would be good to graph over time and make sure it's not regression, but personally I think the brownian motion of individual patches seems like it's not a great idea to gate on every single patch. I personally would be -1 for adding this to projects that I have +2 on. I certainly am not opposed to introducing coverage regression jobs that produce a history of coverage. I would not personally support them being a blocking/gate job, though. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [puppet] Welcome to Puppet 4.0
On 19/Apr/2015 .::. 14:18, Emilien Macchi wrote: We are adding Puppet 4.0 unit testing jobs support as non-voting for now: https://review.openstack.org/175145 The workflow will be: * have the non-voting jobs in check pipeline * make the test work for our modules First, rspec-puppet have to support Puppet 4.0. Hunter already proposed a PR for that [1]! * patch project-config to add the job in gate too, and drop the non-voting tag Since we are already checking Puppet 4.x lint, I'm confident to have the jobs voting very soon. [1] - https://github.com/rodjek/rspec-puppet/pull/265 [2] - https://github.com/rodjek/rspec-puppet/issues/263 Best Regards, Gaël. -- Gaël Chamoulaud Openstack Engineering Mail: [gchamoul|gael] at redhat dot com IRC: strider/gchamoul (Red Hat), gchamoul (Freenode) GnuPG Key ID: 7F4B301 C75F 15C2 A7FD EBC3 7B2D CE41 0077 6A4B A7F4 B301 Freedom...Courage...Commitment...Accountability signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
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/a19939c8f9a7b84b8a4d713fe3d26949e5664089 https://github.com/redhat-openstack/python-keystoneclient/commit/e02d529a87aef8aaca0616c8ee81de224bf1f52a https://github.com/redhat-openstack/neutron/commit/85302b75362df30270383e3a373e60e81b1b2384 (well, it's always the same change) Can't we enhance pbr to build (source/wheel) distributions of applications which don't depend on pbr? Basically implement these patches in pbr? I read somewhere that pkg_resources may also be used to get the version. Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] keystoneclient stable/icehouse broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/20/2015 12:34 AM, Brant Knudson wrote: On Sun, Apr 19, 2015 at 3:07 PM, Brant Knudson b...@acm.org mailto:b...@acm.org wrote: Ever since the stable/icehouse branch was created for python-keystoneclient it's been broken. There are a couple of issues: 1) The gate-python-keystoneclient-python34 job is failing with the error ERROR: InterpreterNotFound: python3.4. I don't know why it's not available. Maybe python3 needs to be installed on the instance or maybe the job should not be run for stable/icehouse. No fix has been proposed for this as far as I know. I'll need some help from infra to figure it out. For this one, the job was just removed via an infra change, see https://review.openstack.org/#/c/175235/ . Should we make it global for all clients? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBAgAGBQJVNLg2AAoJEC5aWaUY1u57TeoIALuFs9uy69I/p6HcIVQc2R6I 0z8aidrbRZsOPsCHIB7V0Xg3zXx9Okxwn+ykuYLHUyyMFPnT+sGPbOCBYVuWxCWb CrP4AKUqdBJC3uvKY3bpxMEe5n4N/IGnEPNPuDmag+mNDh8oy15e1QITlVEIft5f nWOvxZMzztOp0yx/N6bbXlcN9/8FkbK58vP2M6sIKy3Tnt0Ndl30U/IP/1RwJbuT oQcAAAUiNmFExzDrOZXdEs6ZRuGZTOrU+W61SJXF0mhrTh0TxS/7dYY4w6QWDqMq VmYDlHEYUeGKu5y7Gl2Rxy9hWXm0GxF5/CZwzI0647uuPS723Zd8HEBMTvxJjQQ= =cUVP -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings
Hi Boris, thanks for your proposal. As for the agenda, I really think it's important to have it in advance. How are we going to prepare it? Google docs? Who is going to be responsible for that? As for the meeting time, I'm ok with 15:00 UTC, as well as with some earlier time that would satisfy Yair. As for the meeting days, I think that having two meetings on two days in a row (Monday-Tuesday) may be a bit too tough. What if we make one meeting on Tuesday and the other on Thursday? Like the first one near the beginning of the week, and the other towards the end of the week. Best wishes, Mikhail Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Sun, Apr 19, 2015 at 8:28 AM, Yair Fried yfr...@redhat.com wrote: -- *From: *Aleksandr Maretskiy amarets...@mirantis.com *To: *Andrey Kurilin akuri...@mirantis.com *Cc: *Boris Pavlovic bo...@pavlovic.me, OpenStack Development Mailing List openstack-dev@lists.openstack.org, yfr...@redhat.com, yingjun li yingjun...@kylin-cloud.com, Mikhail Dubov msdu...@gmail.com, Oleg Anufriev oanufr...@mirantis.com, Roman Vasilets rvasil...@mirantis.com, Sergey Skripnick sskripn...@mirantis.com *Sent: *Saturday, April 18, 2015 1:00:55 PM *Subject: *Re: [opentack-dev][meetings] Proposing changes in Rally meetings Agreed with everything, but I think it would be a bit better if move one meeting from Monday to another day (Andrey K. is right) On Fri, Apr 17, 2015 at 5:35 PM, Andrey Kurilin akuri...@mirantis.com wrote: - We should start making agenda for each meeting and publish it to Rally wiki +1 +1 * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. It would be nice to post list of high priority patches to etherpad or google docs after each meeting - Move meetings from #openstack-meeting to #openstack-rally chat. doesn't matter for me:) As long as the records are kept. - We should adjust better time for current Rally team. yeah. Current time is not good:( +1 for 15:00 UTC I'd like even earlier, but if it works for everyone else, I'll make the effort. - Do meetings every Monday and Wednesday Monday?) Monday is very hard day... On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic bo...@pavlovic.me wrote: Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally wiki - We should do 2 meeting per week: * First is regular meeting (like we have now) where we are discussing everything * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. Seems like the 2nd meeting is mainly for core, so maybe we can set a better(earlier) time for it among a smaller group? - Move meetings from #openstack-meeting to #openstack-rally chat. - We should adjust better time for current Rally team. Like at the moment it is too late for few of cores in Rally. it's 17:00 UTC and I would like to suggest to make at 15:00 UTC. - Do meetings every Monday and Wednesday Thoughts ? Best regards, Boris Pavlovic -- Best regards, Andrey Kurilin. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Rally] Rally release management changes and future worfklow
Hi all, as some of you probably know, Rally has recently adopted a release-based software development model. The latest release is 0.0.3 (appeared on Apr 14). We have set as our goal to have a new release every 2-3 weeks. Since this is quite ambitious and not so easy to achieve, we are also going to set up a certain release management process: - We are going to have a special IRC meeting at *#openstack-rally* for release discussions. At this weekly meeting, we will discuss the goals for the next release, as well as the progress on them. - The features that are to be implemented in the next release will be posted in a special Google doc https://docs.google.com/document/d/1TX5zpYcTX8AXm-K_h1lzUNVCMvbRgsjUKU-dEYNWLY8/edit?usp=sharing. This doc is open for anyone to view comment. For code reviewers, this document should serve as a link to the patches with the highest priority. - Bugs on Launchpad https://bugs.launchpad.net/rally will be used as well to indicate issues that are to be fixed in the next release. - The release process will be managed by Mikhail Dubov, a Rally core reviewer from Mirantis. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [taskflow][glance][debian] Issue with ordereddict
Hi, Debian are hitting this issue https://bugs.launchpad.net/glance/+bug/1445827. Currently glance and glance_store include ordereddict in their requirements.txt. Since Glance no longer gates on py26 I think it should be ok to remove that requirement from glance and glance_store (both repos have stable branches) which should partially fix the issue. taskflow also seems to have this dependency: $ cat ./.tox/py27/lib/python2.7/site-packages/taskflow-0.7.1.dist-info/ METADATA|grep order Requires-Dist: ordereddict but, unlike glance, it still gates on py26. As I understand it, removing this from taskflow's requirements would cause its py26 gate job to start failing. I'm interested in suggestions from the taskflow folks on what the best thing to do here is. Thanks, -Stuart __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] TC candidacy
confirmed On 04/20/2015 05:56 AM, Thierry Carrez wrote: Hello list, I'm announcing my candidacy for the Technical Committee elections. I have been serving as the chair of the Technical Committee since its inception, but I think we are at a critical point in the evolution of the role of the Technical Committee, and if you allow it, I'd like to be around to help drive us through this transition. In particular, I'd like the Technical Committee to push in 3 new directions during the Liberty cycle: 1. Step out of the way As I explained on [1], I think over the last cycles the TC pushed the regulation and ask for permission cursor so far we actually start preventing things from happening. I'd like us to come back to a point where our community is more trusted by default, where it asks more for forgiveness and less for permission. So I'd like the Technical Committee to look into its processes and see where it can remove itself from the action pipeline, and retreat back to being an appeals board should a problem arise. [1] http://ttx.re/stepping-out-of-the-way.html 2. Start addressing real issues I think it is part of the role of the Technical Committee members to detect, investigate and help solving issues in our development community. As we grow, we can't expect every member to know everything about every project in OpenStack. But each member should be able to dive into specific project(s) and report issues to the group. Subgroups of members should be able to work together on proposing plans to solve long-standing issues. That means spending more than one hour per week on TC matters, which is why I'd like us to give preference in TC elections to candidates who have enough time on their hands, as explained on [2]. [2] http://ttx.re/tech-committee-candidates.html 3. Push toward both ends of the scale space Taking a step back on those last 5 years, I think the natural forces behind OpenStack development made us cover the middle-tier of usage quite well: reasonably large private IaaS systems (~10k VMs) with a need for extra features and accepting the resulting complexity. They did not make us cover the hyper-scale end (public clouds with millions of VMs in a very active usage pattern) that well, because that end is a specific use case that needs specific trade-offs, and not so many users need/push those. And it did not make us cover the basic system end, where people want to deploy a base IaaS compute system without bells and whistles, and without a team of 100 admins, most of them SDN specialists. Our development ecosystem won't naturally go and cover those use cases (lack of business and/or market), but those are essential long-term. We all need extremely-large OpenStack public clouds to burst hybrid workloads to. And we all need people to be able to experiment with OpenStack in POCs, labs and universities. This is the two directions I want to encourage in the near future. More generally, I think it is the role of the Technical Committee members to provide a long-term vision. To influence where we are going, beyond where the market forces push us. To inspire our developers to work (or support work) to cover areas that their employer might not immediately care about in the short term. To make OpenStack better and more universal in the long run. Thanks for your consideration, signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Zaqar] Call for adoption (or exclusion?)
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 this call for adoption and support before taking other actions (also mentioned below). The summit is very close and the Zaqar team is looking forward to it. The upcoming summit represents an important opportunity for Zaqar to integrate with other projects. In the previous summits - since Icehouse's - we've been collecting feedback from the community. We've worked on addressing the many use-cases, we've worked on addressing the concerns raised by the community and we've also kept moving towards reaching the project's goals. As you all know, the project has gone through many ups and downs. We've had some failures in the past and we've also had successes, as a project and as a team. Nevertheless, we've got to the point where it doesn't make much sense to keep pushing new features to the project until it gains adoption. Therefore, I'd like to take advantage of the workshop slots and invite people from other projects to help us/guide us through a hacking session on their projects so we can help with the adoption. The current adoption of Zaqar consist in: - 1 company reachingunning it in production - 1 planning to do it soon - RDO support Unfortunately, the above is certainly not enough for a project to succeed and it makes the time and effort spent on the project not worth it. It's been more than 2 years since we kicked the project off and it's time for it to show some results. The current problem seems to be that many people want the project but no one wants to be the first in adopting Zaqar (which kind of invalidates the premises of the Big tent). In summary, this is a call for adoption before we call it a nice adventure and ask for the project to be excluded from the OpenStack organization based on the lack of adoption and contributions. If you think it's worth it, speak up. Either way, thanks for the support and for reading thus far. On behalf of the Zaqar team, Flavio -- @flaper87 Flavio Percoco pgpYJfTYIMlv6.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all][Zaqar] Call for adoption (or exclusion?)
Tagging as `[all]`, sorry about that! On 20/04/15 14:54 +0200, 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 this call for adoption and support before taking other actions (also mentioned below). The summit is very close and the Zaqar team is looking forward to it. The upcoming summit represents an important opportunity for Zaqar to integrate with other projects. In the previous summits - since Icehouse's - we've been collecting feedback from the community. We've worked on addressing the many use-cases, we've worked on addressing the concerns raised by the community and we've also kept moving towards reaching the project's goals. As you all know, the project has gone through many ups and downs. We've had some failures in the past and we've also had successes, as a project and as a team. Nevertheless, we've got to the point where it doesn't make much sense to keep pushing new features to the project until it gains adoption. Therefore, I'd like to take advantage of the workshop slots and invite people from other projects to help us/guide us through a hacking session on their projects so we can help with the adoption. The current adoption of Zaqar consist in: - 1 company reachingunning it in production - 1 planning to do it soon - RDO support Unfortunately, the above is certainly not enough for a project to succeed and it makes the time and effort spent on the project not worth it. It's been more than 2 years since we kicked the project off and it's time for it to show some results. The current problem seems to be that many people want the project but no one wants to be the first in adopting Zaqar (which kind of invalidates the premises of the Big tent). In summary, this is a call for adoption before we call it a nice adventure and ask for the project to be excluded from the OpenStack organization based on the lack of adoption and contributions. If you think it's worth it, speak up. Either way, thanks for the support and for reading thus far. On behalf of the Zaqar team, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @flaper87 Flavio Percoco pgp4jv4YE2K41.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] weekly meeting - update
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 scheduled on Wednesday (it’s something very mild near the ear), also it’s holiday for a few of the participants that were intending to join. I hope it works for most of you, otherwise we will all be available on next Wednesday 29th as planned. Best regards, Miguel Ángel. On 20/4/2015, at 12:03, Irena Berezovsky irenab@gmail.com wrote: Hi, This week neutron QoS meeting will take place on Tuesday, April 21 at 14:00 UTC on #openstack-meeting-3. Next week, the meeting is back to its original slot: Wed at 14:00 UTC on #openstack-meeting-3. Please join if you are interested. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Miguel Angel Ajo __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated
Hi Sean, Thanks for your work on this. I'll take a closer look tomorrow and remove the downgrade testing from turbo-hipster in line with the TC decision. Cheers, Josh From: Sean Dague s...@dague.net Sent: Monday, 20 April 2015 8:38 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated This proposed patch to drop the db downgrades in Nova master is making Turbo Hipster face plant - https://review.openstack.org/#/c/175010/ It appears that turbo hipster is walking all the way up, then walking back down through migrations, which clearly, is no longer a thing. It would be nice to merge this patch sooner rather than later, so would be great if Turbo hipster could function on migrations without downgrades RSN. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Level 1, 37 Pitt Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad
On 04/20/2015 09:26 AM, Kaneko Takehiro wrote:
Hi,
I'm managing a stackforge project and want to integrate Gerrit with
Launchpad.
Links;
Git: https://git.openstack.org/cgit/stackforge/rack/
Launchpad: https://launchpad.net/python-rack
Project name 'rack' is duplicated in Launchpad so I named our project
'python-rack'.
How can I integrate Gerrit with Launchpad in this case?
Send a patch for project-config repo, file gerrit/projects.yaml and add
to your project:
groups:
python-rack
Btw. this is documented in our infra manual:
http://docs.openstack.org/infra/manual/creators.html#add-the-project-to-the-master-project-list
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Fwd: Integration Gerrit with Launchpad
Andreas,
I missed it.
Thanks for your help.
Takehiro
2015-04-20 16:40 GMT+09:00 Andreas Jaeger a...@suse.com:
On 04/20/2015 09:26 AM, Kaneko Takehiro wrote:
Hi,
I'm managing a stackforge project and want to integrate Gerrit with
Launchpad.
Links;
Git: https://git.openstack.org/cgit/stackforge/rack/
Launchpad: https://launchpad.net/python-rack
Project name 'rack' is duplicated in Launchpad so I named our project
'python-rack'.
How can I integrate Gerrit with Launchpad in this case?
Send a patch for project-config repo, file gerrit/projects.yaml and add to
your project:
groups:
python-rack
Btw. this is documented in our infra manual:
http://docs.openstack.org/infra/manual/creators.html#add-the-project-to-the-master-project-list
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [release] release critical oslo.messaging changes
Sean Dague wrote: Proposed actions are to do both of: - oslo.messaging release with heartbeats off by default (simulates 1.8.0 behavior before the heartbeat code landed) - oslo.messaging requiring py-amqp = 1.4.0, so that if you enable the heartbeating, at least you are protected from the known bug +1 Library releases are still blocked due to master requirements being borked, but that should be solved soon now. Regards, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings
Hi, Agree with all proposes. But maybe it's make sense to do a bigger interval between mitings to make as much as possible work for the next meting. For example Monday/Thursday. Its not principal for me. -Thanks, Roman Vasilets. On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic bo...@pavlovic.me wrote: Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally wiki - We should do 2 meeting per week: * First is regular meeting (like we have now) where we are discussing everything * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. - Move meetings from #openstack-meeting to #openstack-rally chat. - We should adjust better time for current Rally team. Like at the moment it is too late for few of cores in Rally. it's 17:00 UTC and I would like to suggest to make at 15:00 UTC. - Do meetings every Monday and Wednesday Thoughts ? Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
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 status of this issue? Is pbr still used/required to get the version of a package a runtime? I'm not sure that it's an issue in pbr itself. Maybe applications should be fixed instead. (Sorry if it was already discussed and I missed the conclusion.) Victor __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] keystone middleware package changing release method in Liberty
On 04/19/2015 12:54 PM, Morgan Fainberg wrote: On Sunday, April 19, 2015, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 18 April 2015 at 15:20, Morgan Fainberg morgan.fainb...@gmail.com javascript:; wrote: Hi everyone, I wanted to communicate to the community that the Keystone development team has determined that keystonemiddleware package should no longer be released in the same manner as the client libraries. Instead we will be releasing keystonemiddleware in the same manner as Keystone, in the coordinated style. There are a number of reasons but the largest factor is coordinating the requirements. Since keystonemiddleware runs in the process space / interpreter for the services (e.g. Nova) there is no expectation that the version of keystonemiddleware from Juno will run in Liberty nova (or vice versa). With this in mind we will be updating all of the testing and gating to make keystonemiddleware conform in the same manner as the services that utilize it. This change will start with the Liberty release cycle. Kilo and previous releases of OpenStack will continue to rely on the 1.x.x semver releases that mirror the stable/xxx branches of keystonemiddleware. Version numbers and other choices related to this change will be discussed with the Release Management team and updated during the Liberty cycle. This will not impact or change our support plans for the kilo or Juno releases / associated versions of keystonemiddleware. (Full support and maintenance is planned for the lifespan of Juno and Kilo releases).[1] Please feel free to respond in this thread or speak with us on IRC if you have questions of concerns about this change. So how will one match versions between CD deployed Nova and keystonemiddleware? You won't be able to specify what versions work and don't, will you? This concerns me precisely because it runs in the process - there's an expectation of API stability across external API's, but internally things tend to be rather more rocky. In TripleO we regularly ran into servers depending on un-released client library changes, for instance. This will be better than that was, but only because its being explicitly documented as such. 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 when we feel like it we will be doing a standard mile-stone tag for (example) L1, L2, L3, and Liberty final. We will then maintain the backport for stable/Liberty for the life of the release. Those doing CD (or near CD) should be unaffected unless we do something terrible and broken (which could happen but warrants an immediate fix/revert). Keystonemiddleware thankfully has almost no public APIs it receives a header, Validates the token, then returns headers (the public part) to the underlying service. The expectation is CD deployed should work *unless* one of the two projects suddenly has a dependency conflict. Obviously middleware needs to see testing with minimum versions from global-requirements not just maximums (like all projects need). Today middleware is released independent of everything (like a client) but since it is tightly coupled to a set of requirements using 1.5.x with Juno is challenging, since there is a requirements mismatch. Today the only way you know what versions work is by either looking at release dates or by trial/error (or examining requirements). I think it is far better to release middleware like a server project to more clearly indicate release schedule and compatibility. Knowing that 1.3.x receives backports (and tied to Juno), but 1.4.x doesn't because it was released between Juno and kilo, and 1.5.x does again (and is tied to kilo) is just a poor experience for our deployers. I don't want to have to name some release LTS of keystonemiddleware, let's release in a way that make sense for how it is used. Details of the version numbers will be hashed out at the summit and the release management team. (E.g do we move to a 2015.x.x model? Do we increment the X per release in semver, or the 'y'?) This part is not yet determined and requires some discussion. Ok, specific scenario question: I have Neutron API, Nova API, and Cinder API on one API controller box in Kilo. What is the expected upgrade strategy? Will L1, L2, L3 publish to pypi? -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work]
Yes. Totally agree. I hate it that I have to spend a giant amount of effort on one of my clouds to get a working network to my VMs when on the other cloud I get a VM that can talk to the network. Guess which one I think should be the default behavior? Whichever one you choose to deploy with Neutron! Neutron supports a bunch of topologies based on vlans, flat networks, overlays, tenant routers, shared networks, etc. There is no 'default' in this regard. From what I've gathered from these emails, the use case you want is no floating IPs and no tenant routers (what I understood you to be referring to as 'SDN'). If that's the case, just create a few networks with the provider attributes you are interested in and you're done. So what I keep trying to say is that there should be an easy and sane way for me to get a non-natted VM connected to a network that can route packets and I should not need to know anything about the advanced network options available to me, because as a person who just wants a vm that can talk to a network, I'm the default case. neutron net-create MYNET --shared --provider:network_type vlan --provider:physical_network PHYSNET --provider:segmentation_id VLAN_ID Or replace the network type with 'flat' if you don't want any VLAN tagging. This is also possible via the 'networks' tab in the Horizon UI. Please let me know if I've misunderstood what you want. The fact that you aren't interested in floating IPs makes your use case easy. The only one we are having difficulty supporting is the nova network style use case where floating IPs are used with regular networks and no tenant routers. But we're not going to get there by ignoring the needs of the people who want to boot vms that can talk to the network by default. If we're only focusing on the people who want to do fancy network things, and not serving the needs of the people who want to do simple network things - then all we're doing is trading one set of limitations for a second set of limitations, and we're switching which set of people we're excluding from the party. We're not talking about ignoring the needs of these users though. The use of Linux bridge vs. OVS would not be tenant-facing. The API would still support all of the things we have been discussing so far (including floating IPs). The vswitch is just an implementation detail not exposed at the API level. What would be impacted is the ability for the cloud administrator to troubleshoot connectivity or use tooling they are comfortable with if they have a back-ground with Linux bridge vs. OVS. This point has been made clear. On Sat, Apr 18, 2015 at 9:42 AM, Monty Taylor mord...@inaugust.com wrote: On 04/18/2015 10:44 AM, Fox, Kevin M wrote: Replying inline. -Original Message- From: Monty Taylor [mailto:mord...@inaugust.com] Sent: Friday, April 17, 2015 7:53 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] On 04/17/2015 06:48 PM, Rochelle Grober wrote: I know the DevStack issue seems to be solved, but I had to respond.inline From: Fox, Kevin M [mailto:kevin@pnnl.gov] Sent: Friday, April 17, 2015 12:28 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Nova][Neutron] Linuxbridge as the default in DevStack [was: Status of the nova-network to Neutron migration work] No, the complaints from ops I have heard even internally, which I think is being echo'd here is I understand how linux bridge works, I don't opensvswitch. and I don't want to be bothered to learn to debug openvswitch because I don't think we need it. If linux bridge had feature parity with openvswitch, then it would be a reasonable argument or if the users truly didn't need the extra features provided by openvswitch/naas. I still assert though, that linux bridge won't get feature parity with openvswitch and the extra features are actually critical to users (DVR/NaaS), so its worth switching to opevnswitch and learning how to debug it. Linux Bridge is a nonsolution at this point. I'm sorry, but with all due respect - I believe that sounds very much like sticking fingers in ears and not paying attention to the very real needs of users. No, when you have complex software, with multiple classes of users, it is almost impossible to please all your users, in every way. Sime times, you must make hard decisions to make one users experience a little less good for the benefit of the whole community. /me channels Spock here... If it makes the Ops life a little harder, but for every Op that has to learn how to debug openvswitch, 100 users don't have to deal with the difference between nova-network and neutron api's and software built on top of OpensStack that only works with one of them, I think that's worth the tradeoff. Its unfortunate,
Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings
Sorry, I have incorrectly read the proposed meeting days. Meetings of Monday and Wednesday are okay, but I agree with Roman that Monday/Thursday would be a bit better. Best regards, Mikhail Dubov Engineering OPS Mirantis, Inc. E-Mail: mdu...@mirantis.com Skype: msdubov On Mon, Apr 20, 2015 at 12:39 PM, Roman Vasilets rvasil...@mirantis.com wrote: Hi, Agree with all proposes. But maybe it's make sense to do a bigger interval between mitings to make as much as possible work for the next meting. For example Monday/Thursday. Its not principal for me. -Thanks, Roman Vasilets. On Fri, Apr 17, 2015 at 4:26 PM, Boris Pavlovic bo...@pavlovic.me wrote: Rally team, I would like to propose next changes in Rally meetings: - We should start making agenda for each meeting and publish it to Rally wiki - We should do 2 meeting per week: * First is regular meeting (like we have now) where we are discussing everything * Second is release management meeting, where we are discussing priorities for current next release. So core team will know what to review first. - Move meetings from #openstack-meeting to #openstack-rally chat. - We should adjust better time for current Rally team. Like at the moment it is too late for few of cores in Rally. it's 17:00 UTC and I would like to suggest to make at 15:00 UTC. - Do meetings every Monday and Wednesday Thoughts ? Best regards, Boris Pavlovic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Dropping DB Downgrades, need Turbo Hipster tests updated
This proposed patch to drop the db downgrades in Nova master is making Turbo Hipster face plant - https://review.openstack.org/#/c/175010/ It appears that turbo hipster is walking all the way up, then walking back down through migrations, which clearly, is no longer a thing. It would be nice to merge this patch sooner rather than later, so would be great if Turbo hipster could function on migrations without downgrades RSN. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Prefix delegation using dibbler client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 UPD: dibbler packages are now available in all Fedora updates repositories, starting from Fedora 20, plus EPEL7. Packages are called: dibbler-[client|docs|requestor|relay|server]. Specifically, you can locate them at: http://download.eng.brq.redhat.com/pub/fedora/linux/updates/21/x86_64/d/ Please report any bugs with the package at bugzilla.redhat.com. /Ihar On 03/11/2015 05:29 PM, John Davidge (jodavidg) wrote: I am pleased to say that we are now in a good position with this patch. The necessary DHCPv6 client changes have been made available in the latest release of Dibbler (1.0.1) and we’re getting some much appreciated assistance from Ihar and Thomas in having this new version packaged for wide availability - thanks guys. We’ve updated the patch to include tests and it's been brought up-to-date with the latest L3 agent refactoring changes. It is no longer WIP and we would very much appreciate your reviews and feedback. https://review.openstack.org/#/c/158697/ Cheers, John On 24/02/2015 17:40, John Davidge (jodavidg) jodav...@cisco.com wrote: Hello all, We now have a work-in-progress patch up for review: https://review.openstack.org/#/c/158697/ Feedback on our approach is much appreciated. Many thanks, John Davidge OpenStack@Cisco On 20/02/2015 18:28, Ihar Hrachyshka ihrac...@redhat.com wrote: Those are good news! I commented on the pull request. Briefly, we can fetch from git, but would prefer an official release. Thanks, /Ihar On 02/19/2015 11:26 PM, Robert Li (baoli) wrote: Hi Kyle, Ihar, It looks promising to have our patch upstreamed. Please take a look at this pull request https://github.com/tomaszmrugalski/dibbler/pull/26#issuecomment-75 144912 . Most importantly, Tomek asked if it’s sufficient to have the code up in his master branch. I guess you guys may be able to help answer that question since I’m not familiar with openstack release process. Cheers, Robert On 2/13/15, 12:16 PM, Kyle Mestery mest...@mestery.com mailto:mest...@mestery.com wrote: On Fri, Feb 13, 2015 at 10:57 AM, John Davidge (jodavidg) jodav...@cisco.com mailto:jodav...@cisco.com wrote: Hi Ihar, To answer your questions in order: 1. Yes, you are understanding the intention correctly. Dibbler doesn¹t currently support client restart, as doing so causes all existing delegated prefixes to be released back to the PD server. All subnets belonging to the router would potentially receive a new cidr every time a subnet is added/removed. 2. Option 2 cannot be implemented using the current version of dibbler, but it can be done using the version we have modified. Option 3 could possibly be done with the current version of dibbler, but with some major limitations - only one single router namespace would be supported. Once the dibbler changes linked below are reviewed and finalised we will only need to merge a single patch into the upstream dibbler repo. No further patches are anticipated. Yes, you are correct that dibbler is not needed unless prefix delegation is enabled by the deployer. It is intended as an optional feature that can be easily disabled (and probably will be by default). A test to check for the correct dibbler version would certainly be necessary. Testing in the gate will be an issue until the new version of dibbler is merged and packaged in the various distros. I¹m not sure if there is a way to avoid this problem, unless we have devstack install from our updated repo while we wait. To me, this seems like a pretty huge problem. We can't expect distributions to package side-changes to upstream projects. The correct way to solve this problem is to work to get the changes required in the dependent packages upstream into those projects first (dibbler, in this case), and then propose the changes into Neutron to make use of those changes. I don't see how we can proceed with this work until the issues around dibbler has been resolved. John Davidge OpenStack@Cisco On 13/02/2015 16:01, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Thanks for the write-up! See inline. On 02/13/2015 04:34 PM, Robert Li (baoli) wrote: Hi, while trying to integrate dibbler client with neutron to support PD, we countered a few issues with the dibbler client (and server). With a neutron router, we have the qg-xxx interface that is connected to the public network, on which a dhcp server is running on the delegating router. For each subnet with PD enabled, a router port will be created in the neutron router. As a result, a new PD request will be sent that asks for a prefix from the delegating router. Keep in mind that the subnet is added into the router dynamically. We thought about the following options: 1. use a single dibbler client to support the above requirement. This means, the
Re: [openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
On 20 April 2015 at 22:10, Victor Stinner vstin...@redhat.com 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 status of this issue? Is pbr still used/required to get the version of a package a runtime? I believe Redhat patch it out. I don't think they should need to, since we have explicit knobs for distros to use. There is a raised concern about performance from the keystone CLI thread, but I've not seen any followup to confirm that it was indeed testing an *installed* CLI, not one running out of git. I'm not sure that it's an issue in pbr itself. Maybe applications should be fixed instead. I don't think its a bug in the applications. Maybe someone from RedHat can file a bug on pbr describing what goes wrong? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][policy][neutron] oslo.policy API is not powerful enough to switch Neutron to it
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2015 07:49 PM, Salvatore Orlando wrote: == 2. filling in admin context with admin roles == Admin context object is filled with .roles attribute that is a list of roles considered granting admin permissions [4]. The attribute would then be used by plugins that would like to do explicit policy checks. As per Salvatore, this attribute can probably be dropped now that all plugins and services don't rely on it (Salvatore mentioned lbaas mixins as the ones that previously relied on it, but are now not doing it since service split from neutron tree (?)). The problem with dropping the .roles attribute from context object in Liberty is that we, as a responsible upstream with lots of plugins maintained out-of-tree (see the ongoing vendor decomposition effort) would need to support the attribute while it's marked as deprecated for at least one cycle, meaning that if we don't get those oslo.policy internals we rely on in Liberty, we would need to postpone the switch till Mizzle, or rely on private symbols during the switch (while a new release of oslo.policy can easily break us). (BTW the code to extract admin roles is not really robust and has bugs, f.e. it does not handle AndChecks that could be used in context_is_admin. In theory, 'and' syntax would mean that both roles are needed to claim someone is an admin, while the code to extract admin roles handles 'and' the same way as 'or'. For the deprecation time being, we may need to document this limitation.) Roles are normally populated by the keystone middleware. I'm not sure whether we want to drop them altogether from the context, but I would expect the policy engine to use them even after switching to oslo.policy - Plugins should never leverage this kind of information. I am indeede tempted to drop roles and other AAA-related info from the context when it's dispatched to the plugin. This should be done carefully - beyond breaking some plugins it might also impact the notifiers we use to communicate with nova. The function which artificially populates roles in the context was built for artificial contextes, which in some cases were created by plugins performing db operations at startup. I would check if we still have this requirement, and if not remove the function. Ouch, I failed in wording above (ETOOMANYWORDS?). I only meant dropping explicit admin role population from the context object. If there are any reasons to drop the whole attribute, they are irrelevant to oslo.policy adoption discussion, and are worth a separate thread, if at all. Thanks for keeping me honest on the non-sense above! == 3. aggregating core, attribute and subattribute policies == [...] Policies on subattributes are an abomination of nature and they should go. Not sure they can easily go now, without breaking existing setups. I wouldn't require existing deployments to convert their policies unless we are completely locked otherwise. The problem however is that this needs first a rethink about some API extensions - namely the one for external gateway modes. However, as you say we can't reablockedlly do without policies on attributes at the moment. Policies like the following: create_subnetpool:shared: rule:admin_only Led us to implement [1], which uses the symbols which were now made private. You probably forgot to define [1] in your email. At least [1] in the original email seems irrelevant to attribute matching in neutron. That logic is specific for Neutron, which adds semantic value to the policy target. As Ihar says, imposing this on all the other projects might not be welcome and in some cases break the project themselves. So the question to oslo.policy maintainers is: whether all that is said above makes sense, and if so, whether we may now consider exposing those private symbols (+ maybe OrCheck, NotCheck, and other primitives that are logically bound to AndCheck) as part of public API. If community agrees with my analysis and justification for the change, I am happy to propose a patch that would do just that. Making this possilbe would be the quickest path for Neutron. However if the oslo_policy team took this decision it must have been for a solid design reasoning. It is tough to ask to revise a design decision for a single user of a library. Unfortunately a particular Neutron developer took the liberty of playing with authZ policies - I bet he was even proud of what he did: leaving the project with more technical debt. That particular developer should be dealt with appropriately, but this is another story. Do we need a separate neutron-troika gerrit group to handle those cases? I think that the only alternative to making those symbols public in oslo_policy is for Neutron to perform attribute and sub-attribute authZ checks in a different fashion (perhaps an additional engine). This will be a backward
[openstack-dev] [oslo][pbr] getting 0.11 out the door. Maybe even 1.0
So, we've fixed up the semver logic. I went through the review backlog and merged the stuff that was good. One thing in particular was problematic - prompting me to put up https://review.openstack.org/#/c/174646/ - the commit this backs out added per-platform requirements.txt files, which in light of both the related discussions - one for environment markers, and one for stopping using them for install_requires, seems like a bad idea to me. We're working through the ecosystem changes needed to use environment markers pervasively right now, which is a straight forward process, I suspect it will take a month or so to get there, but not much longer. So - I'd like to propose that we release 0.11 as soon as the servers have been released and L is properly open - so that we've the whole release to deal with any fallout. 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. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [oslo][policy][neutron] oslo.policy API is not powerful enough to switch Neutron to it
On 20 April 2015 at 10:03, Ihar Hrachyshka ihrac...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/17/2015 07:49 PM, Salvatore Orlando wrote: == 2. filling in admin context with admin roles == Admin context object is filled with .roles attribute that is a list of roles considered granting admin permissions [4]. The attribute would then be used by plugins that would like to do explicit policy checks. As per Salvatore, this attribute can probably be dropped now that all plugins and services don't rely on it (Salvatore mentioned lbaas mixins as the ones that previously relied on it, but are now not doing it since service split from neutron tree (?)). The problem with dropping the .roles attribute from context object in Liberty is that we, as a responsible upstream with lots of plugins maintained out-of-tree (see the ongoing vendor decomposition effort) would need to support the attribute while it's marked as deprecated for at least one cycle, meaning that if we don't get those oslo.policy internals we rely on in Liberty, we would need to postpone the switch till Mizzle, or rely on private symbols during the switch (while a new release of oslo.policy can easily break us). (BTW the code to extract admin roles is not really robust and has bugs, f.e. it does not handle AndChecks that could be used in context_is_admin. In theory, 'and' syntax would mean that both roles are needed to claim someone is an admin, while the code to extract admin roles handles 'and' the same way as 'or'. For the deprecation time being, we may need to document this limitation.) Roles are normally populated by the keystone middleware. I'm not sure whether we want to drop them altogether from the context, but I would expect the policy engine to use them even after switching to oslo.policy - Plugins should never leverage this kind of information. I am indeede tempted to drop roles and other AAA-related info from the context when it's dispatched to the plugin. This should be done carefully - beyond breaking some plugins it might also impact the notifiers we use to communicate with nova. The function which artificially populates roles in the context was built for artificial contextes, which in some cases were created by plugins performing db operations at startup. I would check if we still have this requirement, and if not remove the function. Ouch, I failed in wording above (ETOOMANYWORDS?). I only meant dropping explicit admin role population from the context object. If there are any reasons to drop the whole attribute, they are irrelevant to oslo.policy adoption discussion, and are worth a separate thread, if at all. Thanks for keeping me honest on the non-sense above! Nah it was me being ambiguous in my reply. We need roles in the context. Otherwise most policy checks would not be applicable anymore. I was making a point that a function that loads and stores them in context generated with operation like get_admin_context or ContextBase.elevated is not needed anymore. Indeed there is a note in the code pointing that out [1]. And here's the patch for doing it [2] (needs some more work) [1] http://git.openstack.org/cgit/openstack/neutron/tree/neutron/policy.py#n472 [2] https://review.openstack.org/#/c/175238/1 == 3. aggregating core, attribute and subattribute policies == [...] Policies on subattributes are an abomination of nature and they should go. Not sure they can easily go now, without breaking existing setups. I wouldn't require existing deployments to convert their policies unless we are completely locked otherwise. Sure. That was just the personal opinion of the developer who was asked to introduce them. The problem however is that this needs first a rethink about some API extensions - namely the one for external gateway modes. However, as you say we can't reablockedlly do without policies on attributes at the moment. Policies like the following: create_subnetpool:shared: rule:admin_only Led us to implement [1], which uses the symbols which were now made private. You probably forgot to define [1] in your email. At least [1] in the original email seems irrelevant to attribute matching in neutron. I was pointing out this (no reference to avoid confusion): http://git.openstack.org/cgit/openstack/neutron/tree/neutron/policy.py#n152 That logic is specific for Neutron, which adds semantic value to the policy target. As Ihar says, imposing this on all the other projects might not be welcome and in some cases break the project themselves. So the question to oslo.policy maintainers is: whether all that is said above makes sense, and if so, whether we may now consider exposing those private symbols (+ maybe OrCheck, NotCheck, and other primitives that are logically bound to AndCheck) as part of public API. If community agrees with my analysis
Re: [openstack-dev] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!
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! On Mon, 20 Apr 2015 05:17, 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 those similar solutions, let’s join together and collectively maintain a single solution. If that sounds good to you, there’s an Infra-spec that’s been approved [2] to refactor much of what the Infrastructure team uses for the upstream “Jenkins” CI to be more easily reusable by many of us. We’ve got stories defined [3], and a few patches submitted. We’re using the gerrit-topic “downstream-puppet” [4]. For example, we’ve got the first part under review for the “Log Server”, which creates your own version of http://logs.openstack.org/ If anyone is interested in migrating towards a common solution, reply, or ping me IRC (asselin) on Freenode #openstack-infra, or join some of the third party ci meetings [5]. Thanks! Ramy [1] https://wiki.openstack.org/wiki/ThirdPartySystems [2] http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html [3] https://storyboard.openstack.org/#!/story/2000101 [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z [5] https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Jaume Devesa Software Engineer at Midokura __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] TC candidacy
Hello list, I'm announcing my candidacy for the Technical Committee elections. I have been serving as the chair of the Technical Committee since its inception, but I think we are at a critical point in the evolution of the role of the Technical Committee, and if you allow it, I'd like to be around to help drive us through this transition. In particular, I'd like the Technical Committee to push in 3 new directions during the Liberty cycle: 1. Step out of the way As I explained on [1], I think over the last cycles the TC pushed the regulation and ask for permission cursor so far we actually start preventing things from happening. I'd like us to come back to a point where our community is more trusted by default, where it asks more for forgiveness and less for permission. So I'd like the Technical Committee to look into its processes and see where it can remove itself from the action pipeline, and retreat back to being an appeals board should a problem arise. [1] http://ttx.re/stepping-out-of-the-way.html 2. Start addressing real issues I think it is part of the role of the Technical Committee members to detect, investigate and help solving issues in our development community. As we grow, we can't expect every member to know everything about every project in OpenStack. But each member should be able to dive into specific project(s) and report issues to the group. Subgroups of members should be able to work together on proposing plans to solve long-standing issues. That means spending more than one hour per week on TC matters, which is why I'd like us to give preference in TC elections to candidates who have enough time on their hands, as explained on [2]. [2] http://ttx.re/tech-committee-candidates.html 3. Push toward both ends of the scale space Taking a step back on those last 5 years, I think the natural forces behind OpenStack development made us cover the middle-tier of usage quite well: reasonably large private IaaS systems (~10k VMs) with a need for extra features and accepting the resulting complexity. They did not make us cover the hyper-scale end (public clouds with millions of VMs in a very active usage pattern) that well, because that end is a specific use case that needs specific trade-offs, and not so many users need/push those. And it did not make us cover the basic system end, where people want to deploy a base IaaS compute system without bells and whistles, and without a team of 100 admins, most of them SDN specialists. Our development ecosystem won't naturally go and cover those use cases (lack of business and/or market), but those are essential long-term. We all need extremely-large OpenStack public clouds to burst hybrid workloads to. And we all need people to be able to experiment with OpenStack in POCs, labs and universities. This is the two directions I want to encourage in the near future. More generally, I think it is the role of the Technical Committee members to provide a long-term vision. To influence where we are going, beyond where the market forces push us. To inspire our developers to work (or support work) to cover areas that their employer might not immediately care about in the short term. To make OpenStack better and more universal in the long run. Thanks for your consideration, -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [opentack-dev][meetings] Proposing changes in Rally meetings
- We should start making agenda for each meeting and publish it to Rally wiki +1 - We should do 2 meeting per week: We can do both things in one meeting. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Fwd: Integration Gerrit with Launchpad
Hi, I'm managing a stackforge project and want to integrate Gerrit with Launchpad. Links; Git: https://git.openstack.org/cgit/stackforge/rack/ Launchpad: https://launchpad.net/python-rack Project name 'rack' is duplicated in Launchpad so I named our project 'python-rack'. How can I integrate Gerrit with Launchpad in this case? Thanks. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [packaging][neutron] --config-dir vs. --config-file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nah, pointing --config-dir, either as one or as one of many arguments, is just plain wrong. We want to have a way to set different configuration values for different services, so merging all configuration files into single pile of Neutron Configuration is not something we should consider. On 04/17/2015 11:17 PM, Kevin Benton wrote: Great! I was just worried that it was going to become one --config-dir option that pointed to /etc/neutron or something. On Fri, Apr 17, 2015 at 7:13 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: On 04/13/2015 09:45 PM, Kevin Benton wrote: What is the order of priority between the same option defined in two files with --config-dir? Should be alphabetically sorted, but it's not yet defined in documentation. I've sent a patch for this: https://review.openstack.org/174883 With '--config-file' args it seemed that it was that the latter ones took priority over the earlier ones. So an admin previously had the ability to abuse that by putting all of the desired global settings in one of the earlier loaded configs and then add some node-specific overrides to the ones loaded later. It's not actually an abuse, but behaviour that is guaranteed by public library documentation, and it's fine to rely on it. Will there still be the ability to do that with RDO? Nothing changes for users who do not want to use conf.d directory and instead store their configuration in upstream config files (like neutron.conf or l3_agent.ini). RDO/neutron only *extends* possibilities to configure services with the new conf.d feature. The order of configuration storages as they are currently loaded in RDO/neutron services is the same for all of them, and can be checked in any systemd service file: https://github.com/openstack-packages/neutron/blob/f20-master/neutron- me tadata-agent.service#L8 https://github.com/openstack-packages/neutron/blob/f20-master/neutron - -me tadata-agent.service#L8 The way it's defined there, conf.d beats all other configuration files. But if you don't buy the new approach, you just don't have any files inside the directory to beat your conventional configuration. On Mon, Apr 13, 2015 at 8:25 AM, Ihar Hrachyshka ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com mailto:ihrac...@redhat.com wrote: Hi, RDO/master (aka Delorean) moved neutron l3 agent to this configuration scheme, configuring l3 (and vpn) agent with --config-dir [1][2][3]. We also provided a way to configure neutron services without ever touching a single configuration file from the package [4] where each service has a config-dir located under /etc/neutron/conf.d/service-name that can be populated by *.conf files that will be automatically read by services during startup. All other distributions are welcome to follow the path. Please don't introduce your own alternative to /etc/neutron/conf.d/... directory to avoid unneeded platform dependent differences in deployment tools. As for devstack, it's not really feasible to introduce such a change there (at least from my perspective), so it's downstream only. [1]: https://github.com/openstack-packages/neutron/blob/f20-master/opensta c k- neutron.spec#L602 https://github.com/openstack-packages/neutron/blob/f20-master/openst a ck- neutron.spec#L602 [2]: https://github.com/openstack-packages/neutron/blob/f20-master/neutron - - l3 https://github.com/openstack-packages/neutron/blob/f20-master/neutron - - l3 -agent.service#L8 [3]: https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master/ o pe nstack-neutron-vpnaas.spec#L97 https://github.com/openstack-packages/neutron-vpnaas/blob/f20-master / ope nstack-neutron-vpnaas.spec#L97 [4]: https://review.gerrithub.io/#/c/229162/ Thanks, /Ihar On 03/13/2015 03:11 PM, Ihar Hrachyshka wrote: Hi all, (I'm starting a new [packaging] tag in this mailing list to reach out people who are packaging our software in distributions and whatnot.) Neutron vendor split [1] introduced situations where the set of configuration files for L3/VPN agent is not stable and depends on which packages are installed in the system. Specifically, fwaas_driver.ini file is now shipped in neutron_fwaas tarball (openstack-neutron-fwaas package in RDO), and so --config-file=/etc/neutron/fwaas_driver.ini argument should be passed to L3/VPN agent *only* when the new package with the file is installed. In devstack, we solve the problem by dynamically generating CLI arguments list based on which services are configured in local.conf [2]. It's not a viable approach in proper distribution packages though, where we usually hardcode arguments [3] in our service manifests (systemd unit files, in case of RDO). The immediate solution to solve the issue would be to use
[openstack-dev] [neutron] [QoS] weekly meeting - update
Hi, This week neutron QoS meeting will take place on Tuesday, April 21 at 14:00 UTC on #openstack-meeting-3. Next week, the meeting is back to its original slot: Wed at 14:00 UTC on #openstack-meeting-3. Please join if you are interested. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1) 9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 Honestly, I'm suspicious of approaches like this. While 90% coverage is clearly better than 0% coverage, it's not clear that 91% coverage is always better than 90% coverage. Especially when you talk about larger and more complex code bases. I actually firmly feel that #3 is wrong. I think it's a lot better to have an early conversation with people about unit tests that need to be written when they don't submit any. Because I think it's a lot less friendly to have someone iterate 10 patches to figure out how to pass a bot's idea of good tests, and then have a reviewer say it's wrong. Honestly, coverage for projects seems to me to be more of an analog measure that would be good to graph over time and make sure it's not regression, but personally I think the brownian motion of individual patches seems like it's not a great idea to gate on every single patch. I personally would be -1 for adding this to projects that I have +2 on. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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-openstack-weekly-meeting-20150421 -- Emilien Macchi signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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
annegen...@justwriteclick.commailto:annegen...@justwriteclick.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Friday, April 17, 2015 at 2:48 PM
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron] [docs] Networking Guide Doc Day - April
23rd
On Fri, Apr 17, 2015 at 3:17 PM, Andreas Jaeger
a...@suse.commailto:a...@suse.com wrote:
On 04/17/2015 08:25 PM, Edgar Magana wrote:
Hello Folks,
I would like to invite all available contributors to help us to complete
the OpenStack Networking Guide.
We are having a Networking Doc Day on April 23rd in order to review the
current guide and make a big push on its content.
Let's use both the Neutron and Docs IRC channels:
#openstack-neutron
#openstack-doc
I suggest to use the #openstack-sprint channel instead, see
https://wiki.openstack.org/wiki/VirtualSprints
The infra team had some sprint with a separate channel and having a separate
place helped to focus.
I like the #openstack-sprint IRC channel idea. It's a nice pairing with doc bug
day, so please close or triage as many networking bugs as you can with this
sprint! We'll be doing bug triaging overall in #openstack-doc.
Thanks,
Anne
Andreas
--
Andreas Jaeger
aj@{suse.comhttp://suse.com,opensuse.orghttp://opensuse.org}
Twitter/Identica: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton, HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Anne Gentle
annegen...@justwriteclick.commailto:annegen...@justwriteclick.com
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Using project-specific channels for official meetings (was: Proposing changes in Rally meetings)
CAD85om3RJg4fDHDKPZpmcboF+=aknm9wqo08bas0eov8dey...@mail.gmail.com 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 additional channel, and increases the chances your meetings will conflict time-wise with others. Using the official meeting channels increases the ability of the community at large to be more involved in those discussions. The new project requirements[1] only say The project has regular meetings on IRC and those meetings are logged but it seems like an oversight to me that it doesn't say they should happen in official meeting channels (at least once the project's application has been accepted). The structure reform resolution[2] did mention use #openstack-meeting channels for their team meetings so I think it's the implied intent there, at least. I've proposed a governance change[3] in hopes of making this clear for others in the future, and updated our Meetings wiki article[4] with an additional sentence in the preamble describing the benefits and linking to related resources. [1] http://governance.openstack.org/reference/new-projects-requirements.html [2] http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html [3] https://review.openstack.org/175427 [4] https://wiki.openstack.org/wiki/Meetings -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. stephen...@hp.com wrote: As it stands currently, neutron on the stable/juno branch behaves as if https://review.openstack.org/#/c/164329/ was never merged. The merge of patch https://review.openstack.org/#/c/153181 puts some LOG.debug statements in the for-loop of the same function. The net result is the unintentional revert of patch https://review.openstack.org/#/c/164329/. I wouldn't call this a revert. Instead, it brought back some context that the original patch dealt with but that the cherry pick did not. This is a regression but not a revert of the patch. According to review.openstack.org, the patch https://review.openstack.org/#/c/153181 merged on April 1st at 1:56 pm. Patch https://review.openstack.org/#/c/164329/ merged on the same day at 2:21 pm. After 153181 merged, the review of 164329 should have triggered a merge conflict error which would have compelled the owner to do a rebase. The merge conflict wasn’t reported and the patches merged anyway. Does this point to a problem with the Jenkins CI system? This was not a problem with the CI system. The infrastructure behaved exactly as it should. The problem happened when [4] was proposed with a lesser scope than [2] and then [3] merged making that extra scope relevant again. I understand why the scope was reduced. It is often necessary to react to changes in context when cherry picking. That is the nature of cherry picking, bringing a patch in to a new context and reacting. It was unfortunate that [3] brought back the relevant context which made the broader scope of the change in [2] necessary and then they merged together. After having given it some thought, I have come to the conclusion that the only way to catch this would have been to include a proper test with [2] and [4] that log debug statements are not executed in the loop. Such a test would have kicked out whichever of [3] and [4] happened to merge last from the gate. It would've been really annoying to fail in the gate but it would have flagged the problem then and there. Really, the failure was in not requiring the tests necessary to prevent regression. Until we add these tests, we will be vulnerable to this regression again. For example, I could merge a new patch to add more logging to this loop today and we'd be back to square one. Carl [1] https://review.openstack.org/#/c/147455 [2] https://review.openstack.org/#/c/149784 [3] https://review.openstack.org/#/c/153181 [4] https://review.openstack.org/#/c/164329 Hi Carl, thanks for analysis. I've sent a regression unit test for master. Once it's merged in master, I'll propose for stable till Juno. [1]: https://review.openstack.org/175445 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNReAAAoJEC5aWaUY1u573MgIAK03+RqvujHgtL9SmyjXBDtn K2awpRWCHM4cmb6Hr6MLVbWNPEC2svjOHWOSRfRZ5vw05xk/ViJ/UM17b7Jz9Drf cTMVJ6G7lzt+XaCQQeB72NbZSEdEfFAcLLNnb9DzVxRjRcvLcu0dV/tpgJ7YeuMn vGwAUJkv+5af6iTy0BmDpJZh2hZ9OFXnesLxCcHY4VKcCX7HiXwhSEjhF1pCOdPd SwRC3MgqL5gcLchoYzcNZ2DtTwK881LixLIh4VhY14VTKzwF1zVJBbar2V5N77RG 9cukeTSsPg+oft/M1JclWUQrQ4G0JWZgE8B5VibpYnF45rYYWDlvAVWwa1pv6uQ= =KgGO -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 5:14 PM, gordon chung g...@live.ca wrote: 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 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. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1)9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 Honestly, I'm suspicious of approaches like this. While 90% coverage is clearly better than 0% coverage, it's not clear that 91% coverage is always better than 90% coverage. Especially when you talk about larger and more complex code bases. I actually firmly feel that #3 is wrong. I think it's a lot better to have an early conversation with people about unit tests that need to be written when they don't submit any. Because I think it's a lot less friendly to have someone iterate 10 patches to figure out how to pass a bot's idea of good tests, and then have a reviewer say it's wrong. Honestly, coverage for projects seems to me to be more of an analog measure that would be good to graph over time and make sure it's not regression, but personally I think the brownian motion of individual patches seems like it's not a great idea to gate on every single patch. I personally would be -1 for adding this to projects that I have +2 on. -Sean -- Sean Dague http://dague.net +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. cheers, gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 are doing a great job. Dont loose heart. Thanks, Kevin From: Flavio Percoco Sent: Monday, April 20, 2015 5:54:54 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [Zaqar] Call for adoption (or exclusion?) 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 this call for adoption and support before taking other actions (also mentioned below). The summit is very close and the Zaqar team is looking forward to it. The upcoming summit represents an important opportunity for Zaqar to integrate with other projects. In the previous summits - since Icehouse's - we've been collecting feedback from the community. We've worked on addressing the many use-cases, we've worked on addressing the concerns raised by the community and we've also kept moving towards reaching the project's goals. As you all know, the project has gone through many ups and downs. We've had some failures in the past and we've also had successes, as a project and as a team. Nevertheless, we've got to the point where it doesn't make much sense to keep pushing new features to the project until it gains adoption. Therefore, I'd like to take advantage of the workshop slots and invite people from other projects to help us/guide us through a hacking session on their projects so we can help with the adoption. The current adoption of Zaqar consist in: - 1 company reachingunning it in production - 1 planning to do it soon - RDO support Unfortunately, the above is certainly not enough for a project to succeed and it makes the time and effort spent on the project not worth it. It's been more than 2 years since we kicked the project off and it's time for it to show some results. The current problem seems to be that many people want the project but no one wants to be the first in adopting Zaqar (which kind of invalidates the premises of the Big tent). In summary, this is a call for adoption before we call it a nice adventure and ask for the project to be excluded from the OpenStack organization based on the lack of adoption and contributions. If you think it's worth it, speak up. Either way, thanks for the support and for reading thus far. On behalf of the Zaqar team, Flavio -- @flaper87 Flavio Percoco __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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=0hl=en https://plus.google.com/hangouts/_/hoaevent/AP36tYenNDpCZC-E2cbqw7050E-AG7RI8SL6bWjGMyuYGKGkCJIcpw?authuser=0hl=en And here’s the link to the youtube video: http://youtu.be/x5wOFwpYGqI http://youtu.be/x5wOFwpYGqI -J__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. Let's not mix the bad unit tests in Nova with the fact that code should be fully covered by well written unit tests. This big task can be split into 2 smaller tasks: 1) Bot that will check that we are covering new code by tests and don't introduce regressions 2) Core and other reviewers ensures that tests are well written. P.S. Unit tests are the first criteria of code quality: if it is hard to cover code by unit tests, code is bad written and should be refactored. Best regards, Boris Pavlovic On Mon, Apr 20, 2015 at 5:26 PM, Dan Smith d...@danplanet.com wrote: 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 being added. It's a huge maintenance burden with very little value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. This I completely agree with. Asking for unit tests is a common thing, and if done early in the review process, is not a non-friendly thing. It's just matter of fact. And if the comment is given with some example unit test code -- or a pointer to a unit test that could be used as an example -- even better. It grows the submitter. +1 I certainly am not opposed to introducing coverage regression jobs that produce a history of coverage. I would not personally support them being a blocking/gate job, though. As Gordon said elsewhere in this thread, I'm not even sure I want to see it reporting as PASS/FAIL. It sounds like this would end up being like our pylint job, which was utterly confused by a lot of things and started to be something that wasn't even reliable enough to use as an advisory test. Recording the data for long-term analysis would be excellent though. It'd be nice to see that we increased coverage over a cycle. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 being added. It's a huge maintenance burden with very little value, IMHO. Good tests for that code would be very valuable of course, but what is there now is not. I think there are cases where going from 90 to 91% mean adding a ton of extra spaghetti just to satisfy a bot, which actually adds nothing but bloat to maintain. This I completely agree with. Asking for unit tests is a common thing, and if done early in the review process, is not a non-friendly thing. It's just matter of fact. And if the comment is given with some example unit test code -- or a pointer to a unit test that could be used as an example -- even better. It grows the submitter. +1 I certainly am not opposed to introducing coverage regression jobs that produce a history of coverage. I would not personally support them being a blocking/gate job, though. As Gordon said elsewhere in this thread, I'm not even sure I want to see it reporting as PASS/FAIL. It sounds like this would end up being like our pylint job, which was utterly confused by a lot of things and started to be something that wasn't even reliable enough to use as an advisory test. Recording the data for long-term analysis would be excellent though. It'd be nice to see that we increased coverage over a cycle. --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. This will help to give us more time to ensure features and related issues to new features can be fully implemented prior to the RC window(s) and limit the rush to land code in the third milestone. Please feel free to discuss questions / concerns here in this thread, in #openstack-keystone on IRC, or during our weekly IRC meeting. Cheers, Morgan Fainberg Sent via mobile __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev If you have a spec to propose, please file it against Backlog until it is approved. Once it is approved, we will move it to the appropriate release; Liberty or later as appropriate. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [chef] A new Core member!
Congratulations!! The same for you JJ! Edgar From: Jay Lau jay.lau@gmail.commailto:jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Sunday, April 19, 2015 at 10:52 PM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [chef] A new Core member! Congrats Zhi Wei! Well deserved! 2015-04-20 11:26 GMT+08:00 Jian Wen wenjia...@gmail.commailto:wenjia...@gmail.com: Congrats On Sat, Apr 18, 2015 at 5:42 AM, JJ Asghar jasg...@chef.iomailto:jasg...@chef.io wrote: Hey everyone! I'd like to announce that Zhiwei Chen has stepped up as a new Core Member. Please take a moment to congratulate him! Thanks Zhiwei! JJ Asghar __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best, Jian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thanks, Jay Lau (Guangya Liu) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 b...@acm.org mailto:b...@acm.org wrote: Ever since the stable/icehouse branch was created for python-keystoneclient it's been broken. There are a couple of issues: 1) The gate-python-keystoneclient-python34 job is failing with the error ERROR: InterpreterNotFound: python3.4. I don't know why it's not available. Maybe python3 needs to be installed on the instance or maybe the job should not be run for stable/icehouse. No fix has been proposed for this as far as I know. I'll need some help from infra to figure it out. For this one, the job was just removed via an infra change, see https://review.openstack.org/#/c/175235/ . Should we make it global for all clients? OK, I went forward and sent the patch to disable them all: https://review.openstack.org/175433 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNRHeAAoJEC5aWaUY1u57VwsIAMiicyHXp/vBS4htkzrZgxt6 lrDJ62bSBktxoNS3nz8UHDukTc1u1u9Ehd4qEtnyjLGKB5YBCb07rqecznov/QAD dv5isXX2eDRkjwKzDHgYo/N+pcR/HhSA99Zgng4qnVuO6UM7WgbXtmjmvVJVr4mq 1Rv57kkOsbIaF8lspV2VnZQlR/zx8I9bEEkLNM63RrlRqYjLkMNTQTGO5QKecD8u h9I21GD0ZIvhPcBYJwZN5pA99E6RCPL8MWn7aXMl7L2UwNEqOaqxf9VV9SY3O+Uv Ctf5gkMcyLGV85IT8963grClJ7JRzwJzgSuOMcxCdHXdrOyOtAZT29VaOifXI7c= =HAwa -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [QoS] weekly meeting - update
On Mon, Apr 20, 2015 at 8:44 AM, Ihar Hrachyshka ihrac...@redhat.com 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 my behalf (thank you!). I got a surgery to one of my kids scheduled on Wednesday (it’s something very mild near the ear), also it’s holiday for a few of the participants that were intending to join. I hope your kid (and you) will be well. ++, hope everything turns out ok! I hope it works for most of you, otherwise we will all be available on next Wednesday 29th as planned. Note that the proposed time conflicts with general neutron meeting. This is true, but I think this is a one-time occurance due to some scheduling concerns. /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVNQK/AAoJEC5aWaUY1u578PcIAL7FkO+wSV4AdkcjIrFNbrcX aHmbV9pYYkUf3GTrBfqBzJ37XqApSCrFinZPpg7vrDfp1TLxvWXBoh8HhBrJUiv3 ItqEGpixotKcuT06E0QSm76p6ZkIFffy68Iudj1dX1bLVuDa7VU59jcBxo9H3EMQ Ei4Vtvf3M1a8wPZV+FHcySzkjrLNJNlgUCHOy/h5JCWC26nGxKHciFYxXz82HQpQ V6o2d+tyLAkJnkIkmbUuRfOLoZaBFwc7ortS1CEt00fMux6EyoNmuhouBZxoUp84 IKZsSDea8QRciHFot1mUA4cF9Up1vFiNuy9K3FOh8VuNCxzc2Un0sGtjIP6zdb0= =Poy8 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 it. It just makes no sense to me that these folks that have put efforts, time and that have helped making Glance what it is today don't have a voice on the specs. Commenting seems to not be enough, apparently. 2) I'd like to encourage a more open communication in our specs review process and including all our current *code* reviewers seems like a good step forward towards that. Things that I'd love to thing and to avoid are: - I'd love to avoid all kind of private emails/conversations. Specs can either be discussed in the review (which is what it's for), team meetings or mailing list. - I'd love for specs to get more attention from other folks. In other words, I'd like to scale our specs review process. There are specs that have sitten there for a bit. - Our *code* reviewers know Glance's code, I want them to have a way to express a stronger opinion/vote. 3) Although this doesn't seem to work for other projects, I believe Glance is not such a big community for this to fail. If anything, it should help us to manage the load a bit better. If there are core-reviewers that simply don't want to do spec reviews, that's fine. 4) If there are non-core reviewers that want to be part of the glance-drivers team then we can vote as we do for new cores. I have to admit that I'm having a hard time to imagine a case like this but... who knows? right? 5) It used to be like this and many of us just found themselves out of the glance-drivers team without notice. It's probably an unexpected side effect of disconnecting LP/gerrit and splitting the teams. Not a big deal, but... Thoughts? Flavio -- @flaper87 Flavio Percoco pgpjvArMypqkP.pgp Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 release. They (and turbo hipster) will need to do this first: https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L963 I'm not sure how you want to handle this, either by converting your data sets, or only converting the ones that master runs. It would be nice to merge this patch as soon as grenade is ready to do so, as it's blocking all other db migrations in master. Thanks! --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 this call for adoption and support before taking other actions (also mentioned below). The summit is very close and the Zaqar team is looking forward to it. The upcoming summit represents an important opportunity for Zaqar to integrate with other projects. In the previous summits - since Icehouse's - we've been collecting feedback from the community. We've worked on addressing the many use-cases, we've worked on addressing the concerns raised by the community and we've also kept moving towards reaching the project's goals. As you all know, the project has gone through many ups and downs. We've had some failures in the past and we've also had successes, as a project and as a team. Nevertheless, we've got to the point where it doesn't make much sense to keep pushing new features to the project until it gains adoption. Therefore, I'd like to take advantage of the workshop slots and invite people from other projects to help us/guide us through a hacking session on their projects so we can help with the adoption. The current adoption of Zaqar consist in: - 1 company reachingunning it in production - 1 planning to do it soon - RDO support Unfortunately, the above is certainly not enough for a project to succeed and it makes the time and effort spent on the project not worth it. It's been more than 2 years since we kicked the project off and it's time for it to show some results. The current problem seems to be that many people want the project but no one wants to be the first in adopting Zaqar (which kind of invalidates the premises of the Big tent). In summary, this is a call for adoption before we call it a nice adventure and ask for the project to be excluded from the OpenStack organization based on the lack of adoption and contributions. If you think it's worth it, speak up. Either way, thanks for the support and for reading thus far. On behalf of the Zaqar team, Flavio __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Thank you for the honesty, here Flavio, I certainly appreciate it. One of the challenges we all currently face is relevance to our mission. I think many developers continue to work diligently in that regard on Zaqar but results need a combination of things, hard work and dedication are only part of that. I am heartened by your courage in taking an honest look at the status of your project and asking for support in understanding its place in the overall picture. Regardless of the outcome I hope you and your fellow developers recognize how much that speaks of your character. I hope you get some honest answers to your question, in turn. Thanks Flavio, Anita. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 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. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1)9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 Honestly, I'm suspicious of approaches like this. While 90% coverage is clearly better than 0% coverage, it's not clear that 91% coverage is always better than 90% coverage. Especially when you talk about larger and more complex code bases. I actually firmly feel that #3 is wrong. I think it's a lot better to have an early conversation with people about unit tests that need to be written when they don't submit any. Because I think it's a lot less friendly to have someone iterate 10 patches to figure out how to pass a bot's idea of good tests, and then have a reviewer say it's wrong. Honestly, coverage for projects seems to me to be more of an analog measure that would be good to graph over time and make sure it's not regression, but personally I think the brownian motion of individual patches seems like it's not a great idea to gate on every single patch. I personally would be -1 for adding this to projects that I have +2 on. -Sean -- Sean Dague http://dague.net +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. cheers, gord __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Multi Region Designate
Hi Kiall, Will appreciate if you can provide your comments on the email below. Regards, Anik From: Anik anik...@yahoo.com To: openstack-dev@lists.openstack.org 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 understand that Designate is providing the API interface to push data into a DNS namespace, so not really related to the region concept in the same way as nova or most other OpenStack services. I think the problem I am highlighting here is that of making updates for zone data to an authoritative DNS server from distributed sources. Take the example of a company which has deployed their resources across multiple OpenStack regions. Now they just want to have a flat DNS namespace (say example.com). They will need to enter host - IP mapping data to some authoritative back end DNS server for this purpose. The records for this zone are being created from multiple regions either through static data entry through designate or via notification handlers from OpenStack events like FIP creation. So my question is can we view designate simply as an data entry vehicle with an API front end where a single (centralized) backend DNS server can be fed data from multiple designate instances ? That way different designate instances in different regions can generate their local RRs for a zone (example.com) and point to the same backend DNS for populating the zone file. Once data goes into the centralized backend DNS, it will be the responsibility of the DNS infrastructure to serve the DNS data in a distributed scale out manner globally for lookups. The problem that will still need to be solved is how do you create major DNS entries, like creating a new zone, with this approach ? I will try to describe a solution for that in a follow up email but wanted to get your opinion first on what I am describing here so far. Regards, Anik -- Message: 1 Date: Tue, 07 Apr 2015 13:00:33 +0100 From: Kiall Mac Innes ki...@macinnes.ie To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Multi Region Designate Message-ID: 5523c6e1.9090...@macinnes.ie Content-Type: text/plain; charset=windows-1252 Hey Anik, So, unlike Nova or other services which really are region aware, Designate, being designed to push data into the global DNS namespace, doesn't have the same concept of regions. Typically, you will either have regions which are close enough to run a Galera/Percona cluster across them without adding too much latency, or you will run asynchronous replication from one region to another using an Active/Standby failover for the core DB. The DNS team @ HP has discussed possible improvements to this many times over the last year or so, but haven't come up with any great solutions to providing what amounts to a global service is a per-region way. We're certainly open to suggestions! :) Thanks, Kiall On 23/03/15 04:41, Anik wrote: Hi, Are there any plans to have multi region DNS service through designate ? For example If a tenant has projects in multiple regions and wants to use a single (flat) external domain name space for floating IPs, what is the proposed solution for such a use case using Designate ? Regards, Anik __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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. Also, a test that says coverage increased might lead to lazy +2s is very similar to this code made it into the tree because it had a ton of (bad) tests that made it look well-tested, which we already know is true :) P.S. Unit tests are the first criteria of code quality: if it is hard to cover code by unit tests, code is bad written and should be refactored. Totally agree. Draw what conclusions you will about my feelings on the quality of the code that is tested by those tests :) --Dan __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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: CAD85om3RJg4fDHDKPZpmcboF+=aknm9wqo08bas0eov8dey...@mail.gmail.com 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 additional channel, and increases the chances your meetings will conflict time-wise with others. Using the official meeting channels increases the ability of the community at large to be more involved in those discussions. The new project requirements[1] only say The project has regular meetings on IRC and those meetings are logged but it seems like an oversight to me that it doesn't say they should happen in official meeting channels (at least once the project's application has been accepted). The structure reform resolution[2] did mention use #openstack-meeting channels for their team meetings so I think it's the implied intent there, at least. I've proposed a governance change[3] in hopes of making this clear for others in the future, and updated our Meetings wiki article[4] with an additional sentence in the preamble describing the benefits and linking to related resources. [1] http://governance.openstack.org/reference/new-projects-requirements.html [2] http://governance.openstack.org/resolutions/20141202-project-structure-reform-spec.html [3] https://review.openstack.org/175427 [4] https://wiki.openstack.org/wiki/Meetings __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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 should use the extra_dhcp_opts API extension to set the IPXE tag. http://specs.openstack.org/openstack/neutron-specs/specs/api/extra_dhcp_options__extra-dhcp-opt_.html Thoughts? -- Sean M. Collins __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 with well written unit tests. One of the nice thing is coverage job. In Rally we are running it against every check which allows us to get detailed information about coverage before merging patch: http://logs.openstack.org/84/175084/1/check/rally-coverage/c61d5e1/cover/ This helped Rally core team to automate checking that new/changed code is covered by unit tests and we raised unit test coverage from ~78% to almost 91%. But it produces few issues: 1) 9k nitpicking - core reviewers have to put -1 if something is not covered by unit tests 2) core team scaling issues - core team members spend a lot of time just checking that whole code is covered by unit test and leaving messages like this should be covered by unit test 3) not friendly community - it's not nice to get on your code -1 from somebody that is asking just to write unit tests 4) coverage regressions - sometimes we accidentally accept patches that reduce coverage To resolve this issue I improved a bit coverage job in Rally project, and now it compares master vs master + patch coverage. If new coverage is less than master job is marked as -1. Here is the patch for job enhancement: https://review.openstack.org/#/c/174645/ Here is coverage job in action: patch https://review.openstack.org/#/c/174677/ job message http://logs.openstack.org/77/174677/4/check/rally-coverage/ba49c90/console.html#_2015-04-17_15_57_17_695 The link to the important line was key, because without it, just clicking through from the review was incomprehensible to me. Can I suggest some whitespace or bordering so we can see where the error is easily? 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 pointer to how things probably should be, but sometimes it's entirely o-k to regress this number a few points. Also graphing this over time in a post-commit job seems like a no-brainer. Designate has started doing this - it is still a WIP as we continue tweaking settings, but we have a dashboard here - http://sonar.designate-ci.com/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
