[openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
Hi there, TroveClient just got rejected by Debian FTP masters. Reply from Luke Faraone is below. In general, I would strongly advise that a clean COPYRIGHT-HOLDER file is created with the copyright holders in them. Why? Because it is hard to distinguish between authors and copyright holders, which are very distinct things. Listing the authors in debian/copyright doesn't seem to satisfy the FTP masters as well... :( FYI, my reply was that I knew some of the authors were working for Rackspace, because I met them in Portland, and that I knew Rackspace was one of the copyright holders. Though that's of course not enough for the Debian FTP masters. Your thoughts? Cheers, Thomas Goirand (zigo) Original Message Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED Date: Sat, 19 Oct 2013 04:00:19 + From: Luke Faraone ftpmas...@ftp-master.debian.org To: PKG OpenStack openstack-de...@lists.alioth.debian.org, Thomas Goirand z...@debian.org Dear maintainer, debian/copyright is **not** an AUTHORS list. This package appears to be Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some other companies, not copyrighted each individual employee at HP who worked on it. Your automated debian/copyright generation is most probably suboptimal for most packages, and is most certainly not a substitute for manual review. One missed copyright holder: python-troveclient-0.1.4\troveclient\base.py: Copyright 2010 Jacob Kaplan-Moss Cheers, Luke Faraone FTP Team === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ Openstack-devel mailing list openstack-de...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/openstack-devel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Swift] Havana Release Notes Known Issues is talking about Nova (Re: [Openstack] OpenStack 2013.2 (Havana) is released !)
Hi Thierry, John, In Havana release notes, Swift known issues section is talking about Nova Cells issue. Could you confirm? https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues Thanks, Akihiro On Thu, Oct 17, 2013 at 11:23 PM, Thierry Carrez thie...@openstack.org wrote: Hello everyone, It is my great pleasure to announce the final release of OpenStack 2013.2. It marks the end of the Havana 6-month-long development cycle, which saw the addition of two integrated components (Ceilometer and Heat), the completion of more than 400 feature blueprints and the fixing of more than 3000 reported bugs ! You can find source tarballs for each integrated project, together with lists of features and bugfixes, at: OpenStack Compute:https://launchpad.net/nova/havana/2013.2 OpenStack Object Storage: https://launchpad.net/swift/havana/1.10.0 OpenStack Image Service: https://launchpad.net/glance/havana/2013.2 OpenStack Networking: https://launchpad.net/neutron/havana/2013.2 OpenStack Block Storage: https://launchpad.net/cinder/havana/2013.2 OpenStack Identity: https://launchpad.net/keystone/havana/2013.2 OpenStack Dashboard: https://launchpad.net/horizon/havana/2013.2 OpenStack Metering: https://launchpad.net/ceilometer/havana/2013.2 OpenStack Orchestration: https://launchpad.net/heat/havana/2013.2 The Havana Release Notes contain an overview of the key features, as well as upgrade notes and current lists of known issues. You can access them at: https://wiki.openstack.org/wiki/ReleaseNotes/Havana In 19 days, our community will gather in Hong-Kong for the OpenStack Summit: 4 days of conference to discuss all things OpenStack and a Design Summit to plan the next 6-month development cycle, codenamed Icehouse. It's not too late to join us there, see http://www.openstack.org/summit/openstack-summit-hong-kong-2013/ for more details. Congratulations to everyone who contributed to this development cycle and participated in making this awesome release possible ! -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] Havana Release Notes Known Issues is talking about Nova (Re: [Openstack] OpenStack 2013.2 (Havana) is released !)
I may have put that in the wrong spot. Oops. On Oct 18, 2013, at 11:11 PM, Akihiro Motoki amot...@gmail.com wrote: Hi Thierry, John, In Havana release notes, Swift known issues section is talking about Nova Cells issue. Could you confirm? https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues Thanks, Akihiro On Thu, Oct 17, 2013 at 11:23 PM, Thierry Carrez thie...@openstack.org wrote: Hello everyone, It is my great pleasure to announce the final release of OpenStack 2013.2. It marks the end of the Havana 6-month-long development cycle, which saw the addition of two integrated components (Ceilometer and Heat), the completion of more than 400 feature blueprints and the fixing of more than 3000 reported bugs ! You can find source tarballs for each integrated project, together with lists of features and bugfixes, at: OpenStack Compute:https://launchpad.net/nova/havana/2013.2 OpenStack Object Storage: https://launchpad.net/swift/havana/1.10.0 OpenStack Image Service: https://launchpad.net/glance/havana/2013.2 OpenStack Networking: https://launchpad.net/neutron/havana/2013.2 OpenStack Block Storage: https://launchpad.net/cinder/havana/2013.2 OpenStack Identity: https://launchpad.net/keystone/havana/2013.2 OpenStack Dashboard: https://launchpad.net/horizon/havana/2013.2 OpenStack Metering: https://launchpad.net/ceilometer/havana/2013.2 OpenStack Orchestration: https://launchpad.net/heat/havana/2013.2 The Havana Release Notes contain an overview of the key features, as well as upgrade notes and current lists of known issues. You can access them at: https://wiki.openstack.org/wiki/ReleaseNotes/Havana In 19 days, our community will gather in Hong-Kong for the OpenStack Summit: 4 days of conference to discuss all things OpenStack and a Design Summit to plan the next 6-month development cycle, codenamed Icehouse. It's not too late to join us there, see http://www.openstack.org/summit/openstack-summit-hong-kong-2013/ for more details. Congratulations to everyone who contributed to this development cycle and participated in making this awesome release possible ! -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] Havana Release Notes Known Issues is talking about Nova (Re: [Openstack] OpenStack 2013.2 (Havana) is released !)
Ah, I know what happened. This is corrected now. - Chris On Oct 19, 2013, at 12:27 AM, Chris Behrens cbehr...@codestud.com wrote: I may have put that in the wrong spot. Oops. On Oct 18, 2013, at 11:11 PM, Akihiro Motoki amot...@gmail.com wrote: Hi Thierry, John, In Havana release notes, Swift known issues section is talking about Nova Cells issue. Could you confirm? https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues Thanks, Akihiro On Thu, Oct 17, 2013 at 11:23 PM, Thierry Carrez thie...@openstack.org wrote: Hello everyone, It is my great pleasure to announce the final release of OpenStack 2013.2. It marks the end of the Havana 6-month-long development cycle, which saw the addition of two integrated components (Ceilometer and Heat), the completion of more than 400 feature blueprints and the fixing of more than 3000 reported bugs ! You can find source tarballs for each integrated project, together with lists of features and bugfixes, at: OpenStack Compute:https://launchpad.net/nova/havana/2013.2 OpenStack Object Storage: https://launchpad.net/swift/havana/1.10.0 OpenStack Image Service: https://launchpad.net/glance/havana/2013.2 OpenStack Networking: https://launchpad.net/neutron/havana/2013.2 OpenStack Block Storage: https://launchpad.net/cinder/havana/2013.2 OpenStack Identity: https://launchpad.net/keystone/havana/2013.2 OpenStack Dashboard: https://launchpad.net/horizon/havana/2013.2 OpenStack Metering: https://launchpad.net/ceilometer/havana/2013.2 OpenStack Orchestration: https://launchpad.net/heat/havana/2013.2 The Havana Release Notes contain an overview of the key features, as well as upgrade notes and current lists of known issues. You can access them at: https://wiki.openstack.org/wiki/ReleaseNotes/Havana In 19 days, our community will gather in Hong-Kong for the OpenStack Summit: 4 days of conference to discuss all things OpenStack and a Design Summit to plan the next 6-month development cycle, codenamed Icehouse. It's not too late to join us there, see http://www.openstack.org/summit/openstack-summit-hong-kong-2013/ for more details. Congratulations to everyone who contributed to this development cycle and participated in making this awesome release possible ! -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] openstack-dev][nova][neturon] NoopFirewallDriver lead nova boot/show/list failure.
Hi ALL, There is bug https://bugs.launchpad.net/python-neutronclient/+bug/1232965. When set firewall_driver = neutron.agent.firewall.NoopFirewallDriver in /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini , Nova operations (list/show/boot) will fail. due to Nuetron client raises NotFound security_group exception. I submit a patch for Nova to fix nova show/list failure. See https://review.openstack.org/#/c/52597/ My question is , which side (Neutron, NeutronClient ,Nova) should fix this , what's the best solution , current I just catch the exception and return empty list of security_group . Any thoughts ? Best Regards --- Eric Guo 郭长波 Cloud Solutions and Openstack Development China System Technology Laboratories (CSTL), IBM Tel:86-10-82452019 Internet Mail: guoc...@cn.ibm.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][keystone] Adding client library related tests to tempest
On Fri, Oct 18, 2013 at 01:48:08PM -0400, Sean Dague wrote: So v3 keystone API is one thing, but I'm a little concerned with moving the client testing to Tempest haphazardly. If we are testing the API surface on the servers, the clients should be able to correctly test all of this via a mock of those API returns, which would let us separate concerns here and keep the client tests close to their code as unit tests. IME testing the API and clients separately via mocked interfaces is not enough, you still end up with several categories of bugs which can (and do, regularly) sneak through: - The API implementation is wrong, and there is a corresponding mistake in the unit tests. This is obviously a common problem with any unit test containing mock responses, here's a recent example of such an issue, discovered while writing these tests.. https://review.openstack.org/#/c/51448/ - The API implementation is correct, but there are undocumented or non-obvious restrictions on combinations of arguments which work, or are allowed. This is a common issue with keystone IME, where some combinations work, and others give a 403 response with no information about why. So you end up reading the API code or trying stuff at random, whereas with a set of client tests, we can demonstrate and verify that all required/expected usage patterns work and stay working. We're actually actively trying to figure out what can migrate out of tempest back to the integrated projects, so that we get our biggest bang for our buck. In that case, one could argue that the best thing is to only test via the clients, and move the API-surface tests back into the projects as integration tests. IMHO it makes sense to make the gate tests the most end-to-end tests possible, using the primary integration point for each project (which in most cases is the client not direct API interaction.) Thanks for all the discussion so far, I'll make sure I attend the summit session so we can figure out the next steps. Also I apologize if my patches caught you off-guard, I (mis)interpreted my initial chat with dkranz as blessing to proceed, and with Havana deadlines looming I just hacked out the tests in an effort to get my patch into keystoneclient. Thanks, Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700: Hi there, TroveClient just got rejected by Debian FTP masters. Reply from Luke Faraone is below. In general, I would strongly advise that a clean COPYRIGHT-HOLDER file is created with the copyright holders in them. Why? Because it is hard to distinguish between authors and copyright holders, which are very distinct things. Listing the authors in debian/copyright doesn't seem to satisfy the FTP masters as well... :( FYI, my reply was that I knew some of the authors were working for Rackspace, because I met them in Portland, and that I knew Rackspace was one of the copyright holders. Though that's of course not enough for the Debian FTP masters. Your thoughts? Recently there was a movement to remove the copyright headers from all the files in OpenStack. Some folk disagreed with this movement, and the compromise was that they were discouraged but allowed. Nobody who writes code wants to hear that they have to think about licensing, copyrights, etc. But at a bare minimum, copyrights should be asserted somewhere in each project's repository. Now, some people will say thats what we have git for. I suggest to those who would suggest we just trust git commit logs that this is not sufficient. For instance, I submit code with my personal email address, even though it is all work-for-hire and thus sending copyrights to HP rather than me individually. I suggest that we just put Copyright headers back in the source files. That will make Debian's licensecheck work fairly automatically. A single file that tries to do exactly what debian/copyright would do seems a bit odd. Cheers, Thomas Goirand (zigo) Original Message Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED Date: Sat, 19 Oct 2013 04:00:19 + From: Luke Faraone ftpmas...@ftp-master.debian.org To: PKG OpenStack openstack-de...@lists.alioth.debian.org, Thomas Goirand z...@debian.org Dear maintainer, debian/copyright is **not** an AUTHORS list. This package appears to be Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some other companies, not copyrighted each individual employee at HP who worked on it. Your automated debian/copyright generation is most probably suboptimal for most packages, and is most certainly not a substitute for manual review. One missed copyright holder: python-troveclient-0.1.4\troveclient\base.py: Copyright 2010 Jacob Kaplan-Moss Cheers, Luke Faraone FTP Team === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] Havana Release Notes Known Issues is talking about Nova (Re: [Openstack] OpenStack 2013.2 (Havana) is released !)
Thanks for the quick fix. I noticed it during translating the release note. On Sat, Oct 19, 2013 at 4:45 PM, Chris Behrens cbehr...@codestud.com wrote: Ah, I know what happened. This is corrected now. - Chris On Oct 19, 2013, at 12:27 AM, Chris Behrens cbehr...@codestud.com wrote: I may have put that in the wrong spot. Oops. On Oct 18, 2013, at 11:11 PM, Akihiro Motoki amot...@gmail.com wrote: Hi Thierry, John, In Havana release notes, Swift known issues section is talking about Nova Cells issue. Could you confirm? https://wiki.openstack.org/wiki/ReleaseNotes/Havana#Known_Issues Thanks, Akihiro On Thu, Oct 17, 2013 at 11:23 PM, Thierry Carrez thie...@openstack.org wrote: Hello everyone, It is my great pleasure to announce the final release of OpenStack 2013.2. It marks the end of the Havana 6-month-long development cycle, which saw the addition of two integrated components (Ceilometer and Heat), the completion of more than 400 feature blueprints and the fixing of more than 3000 reported bugs ! You can find source tarballs for each integrated project, together with lists of features and bugfixes, at: OpenStack Compute:https://launchpad.net/nova/havana/2013.2 OpenStack Object Storage: https://launchpad.net/swift/havana/1.10.0 OpenStack Image Service: https://launchpad.net/glance/havana/2013.2 OpenStack Networking: https://launchpad.net/neutron/havana/2013.2 OpenStack Block Storage: https://launchpad.net/cinder/havana/2013.2 OpenStack Identity: https://launchpad.net/keystone/havana/2013.2 OpenStack Dashboard: https://launchpad.net/horizon/havana/2013.2 OpenStack Metering: https://launchpad.net/ceilometer/havana/2013.2 OpenStack Orchestration: https://launchpad.net/heat/havana/2013.2 The Havana Release Notes contain an overview of the key features, as well as upgrade notes and current lists of known issues. You can access them at: https://wiki.openstack.org/wiki/ReleaseNotes/Havana In 19 days, our community will gather in Hong-Kong for the OpenStack Summit: 4 days of conference to discuss all things OpenStack and a Design Summit to plan the next 6-month development cycle, codenamed Icehouse. It's not too late to join us there, see http://www.openstack.org/summit/openstack-summit-hong-kong-2013/ for more details. Congratulations to everyone who contributed to this development cycle and participated in making this awesome release possible ! -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote: I suggest that we just put Copyright headers back in the source files. That will make Debian's licensecheck work fairly automatically. A single file that tries to do exactly what debian/copyright would do seems a bit odd. The problem here is that the copyright headers were wrong. They aren't religiously added to, and sometimes people have tried to gift code to the Foundation by saying the code is copyright the Foundation, which isn't always true. So, we can't lean on these headers for accurate statements of copyright. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa][keystone] Adding client library related tests to tempest
On 10/19/2013 04:46 AM, Steven Hardy wrote: On Fri, Oct 18, 2013 at 01:48:08PM -0400, Sean Dague wrote: So v3 keystone API is one thing, but I'm a little concerned with moving the client testing to Tempest haphazardly. If we are testing the API surface on the servers, the clients should be able to correctly test all of this via a mock of those API returns, which would let us separate concerns here and keep the client tests close to their code as unit tests. IME testing the API and clients separately via mocked interfaces is not enough, you still end up with several categories of bugs which can (and do, regularly) sneak through: - The API implementation is wrong, and there is a corresponding mistake in the unit tests. This is obviously a common problem with any unit test containing mock responses, here's a recent example of such an issue, discovered while writing these tests.. https://review.openstack.org/#/c/51448/ Ok, fair, but was that API being tested in Tempest? (grep -r impersonation in tempest tree suggests not). To be fair I wasn't suggesting mocking was good enough by itself, it was the combination of: * API coverage in Tempest to ensure API contract * mocking in the project based on the fact that API was solidified by Tempest real testing - The API implementation is correct, but there are undocumented or non-obvious restrictions on combinations of arguments which work, or are allowed. This is a common issue with keystone IME, where some combinations work, and others give a 403 response with no information about why. So you end up reading the API code or trying stuff at random, whereas with a set of client tests, we can demonstrate and verify that all required/expected usage patterns work and stay working. We're actually actively trying to figure out what can migrate out of tempest back to the integrated projects, so that we get our biggest bang for our buck. In that case, one could argue that the best thing is to only test via the clients, and move the API-surface tests back into the projects as integration tests. Here I think we'll have to disagree. The OpenStack API is the contract. While other OpenStack components are using the python clients for convenience, the API should be equally accessible on any language. And having the API testing in tempest has prevented some big compatibility breaks in our API, so that's going to remain important. And I think this is going to be an important part of this discussion because of the role that the clients have in smoothing over potential issues in the API. So it will be important that client library testing, if/when we add it, comes after the equivalent API testing being put in place. Ensuring API solidity is first order priority, and today there a huge holes in that for most projects in tempest (keystone definitely in that list). IMHO it makes sense to make the gate tests the most end-to-end tests possible, using the primary integration point for each project (which in most cases is the client not direct API interaction.) Definitely agree we should have plenty of end-to-end tests in the gate, it's the reason we've got the scenario tests, to do exactly this kind of through testing. Thanks for all the discussion so far, I'll make sure I attend the summit session so we can figure out the next steps. Also I apologize if my patches caught you off-guard, I (mis)interpreted my initial chat with dkranz as blessing to proceed, and with Havana deadlines looming I just hacked out the tests in an effort to get my patch into keystoneclient. No worries, it was just new to most of us, and we were really deliberate about the test directory structure and scope out of last summit, so it's just something I don't want to change lightly. But the discussion is flowing now, which is all good... and let's us figure out the best way forward. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Announce of Rally - benchmarking system for OpenStack
David, Yes, that is the goal. We should be able to get information about how it works, not only that it works. And get such interesting results: https://wiki.openstack.org/wiki/Rally#How_influence_amqp_rpc_single_reply_queue_on_performance Best regards, Boris Pavlovic --- Mirantis Inc. On Fri, Oct 18, 2013 at 8:57 PM, David Kranz dkr...@redhat.com wrote: On 10/18/2013 12:17 PM, Boris Pavlovic wrote: John, Actually seems like a pretty good suggestion IMO, at least something worth some investigation and consideration before quickly discounting it. Rather than that's not what tempest is, maybe it's something tempest could do. Don't know, not saying one way or the other, just wondering if it's worth some investigation or thought. These investigations I made before start working around Rally. It was about 3 months ago. It is not quickly discounting I didn't have yesterday time to make long response, so I will write it today: I really don't like to make a copy of another projects, so I tried to reuse all projects libs that we already have. To explain why we shouldn't merge Rally Tempest in one project (and should keep both) we should analyze their use cases. 1. DevStack - one click and get your OpenStack cloud from sources 2. Tempest - one click and get your OpenStack Cloud verified Both of these projects are great, because they are very useful and solve complicated tasks without pain for end user. (and I like them) 3. Rally is also one click system that solve OpenStack benchmarking. To clarify situation. We should analyze what I mean by one click benchmarking and what are the use cases. Use Cases: 1. Investigate how deployments influence on OS performance (find the set of good OpenStack deployment architectures) 2. Automatically get numbers profiling info about how your changes influence on OS performance 3. Using Rally profiler detect scale performance issues. Like here when we are trying to delete 3 VMs by one request they are deleted one by one because of DB lock on quotas table http://37.58.79.43:8080/traces/0011f252c9d98e31 4. Determine maximal load that could handle production cloud To cover these cases we should actually test OpenStack deployments making simultaneously OpenStack API calls. So to get results we have to: 1. Deploy OpenStack cloud somewhere. (Or get existing cloud) 2. Verify It 3. Run Benchmarks 4. Collect all results present it in human readable form. The goal of Rally was designed to automate these steps: 1.a Use existing cloud. 1.b.1 Automatically get (virtual) Servers from (soft layer, Amazon, RackSpace or you private public cloud, or OpenStack cloud) 1.b.2 DeployOpenStack on these servers from source (using Devstack, Anvli, Fuel or TrippleO...). 1.b.3 Patch this OpenStack with tomograph to get profiling information (I hope we will merge these patches into upstream). 2. Using tempest verify this cloud (we are going to switch from fuel-ostf-tests) 3. Run specified parametrized (to be able to make different load) benchmark scenarios 4. Collect all information about execution present it in human readable form. (Tomograph, Zipking, matplotlib...) So I am not sure that we should put inside Tempest Rally, because Rally use tempest. It is something like putting Nova into Cinder =) Also putting Tempest into Rally is not a good idea. (same as putting Cinder back to Nova). Best regards, Boris Pavlovic --- Mirantis Inc. On Thu, Oct 17, 2013 at 11:56 PM, John Griffith john.griff...@solidfire.com wrote: On Thu, Oct 17, 2013 at 1:44 PM, Jay Pipes jaypi...@gmail.com wrote: On 10/17/2013 03:32 PM, Boris Pavlovic wrote: Jay, Or, alternately, just have Rally as part of Tempest. Actually, tempest is used only to verify that cloud works properly. And verification is only small part of the Rally. At this moment we are using fuel-ostf-tests, but we are going to use tempest to verify cloud. OK, cool... was just a suggestion :) Tempest has a set of stress tests [1] which are kind of related, which is the only reason I brought it up. Best, -jay [1] https://github.com/openstack/tempest/tree/master/tempest/stress ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Actually seems like a pretty good suggestion IMO, at least something worth some investigation and consideration before quickly discounting it. Rather than that's not what tempest is, maybe it's something tempest could do. Don't know, not saying one way or the other, just wondering if it's worth some investigation or thought. By the way, VERY COOL!! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/19/2013 04:52 AM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700: Hi there, TroveClient just got rejected by Debian FTP masters. Reply from Luke Faraone is below. In general, I would strongly advise that a clean COPYRIGHT-HOLDER file is created with the copyright holders in them. Why? Because it is hard to distinguish between authors and copyright holders, which are very distinct things. Listing the authors in debian/copyright doesn't seem to satisfy the FTP masters as well... :( FYI, my reply was that I knew some of the authors were working for Rackspace, because I met them in Portland, and that I knew Rackspace was one of the copyright holders. Though that's of course not enough for the Debian FTP masters. Your thoughts? Recently there was a movement to remove the copyright headers from all the files in OpenStack. Some folk disagreed with this movement, and the compromise was that they were discouraged but allowed. This is not true. The compromise is that they are not required, and that people would stop rejecting patches if they did not include a license header. At no point in time, to my knowledge, did we EVER reach an agreement that they are actually discouraged. We merely acknowledged that we have developer apathy on this point and weren't going to get it right. Nobody who writes code wants to hear that they have to think about licensing, copyrights, etc. But at a bare minimum, copyrights should be asserted somewhere in each project's repository. Also not true. I write code, I care a great deal about licensing and copyrights. I'm sad that ANY developer working on Open Source software does not care about these things - I think it's very lame when they don't. Now, some people will say thats what we have git for. I suggest to those who would suggest we just trust git commit logs that this is not sufficient. For instance, I submit code with my personal email address, even though it is all work-for-hire and thus sending copyrights to HP rather than me individually. Yup. Agree. git is not sufficient. The only thing that is sufficient is a positive assertion by an informed developer of their copyright. I suggest that we just put Copyright headers back in the source files. That will make Debian's licensecheck work fairly automatically. A single file that tries to do exactly what debian/copyright would do seems a bit odd. Cheers, Thomas Goirand (zigo) Original Message Subject: [Openstack-devel] python-troveclient_0.1.4-1_amd64.changes REJECTED Date: Sat, 19 Oct 2013 04:00:19 + From: Luke Faraone ftpmas...@ftp-master.debian.org To: PKG OpenStack openstack-de...@lists.alioth.debian.org, Thomas Goirand z...@debian.org Dear maintainer, debian/copyright is **not** an AUTHORS list. This package appears to be Copyright (c) 2013 Hewlett-Packard Development Company, L.P., and some other companies, not copyrighted each individual employee at HP who worked on it. Your automated debian/copyright generation is most probably suboptimal for most packages, and is most certainly not a substitute for manual review. One missed copyright holder: python-troveclient-0.1.4\troveclient\base.py: Copyright 2010 Jacob Kaplan-Moss Cheers, Luke Faraone FTP Team === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/19/2013 05:49 AM, Michael Still wrote: On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote: I suggest that we just put Copyright headers back in the source files. That will make Debian's licensecheck work fairly automatically. A single file that tries to do exactly what debian/copyright would do seems a bit odd. The problem here is that the copyright headers were wrong. They aren't religiously added to, and sometimes people have tried to gift code to the Foundation by saying the code is copyright the Foundation, which isn't always true. So, we can't lean on these headers for accurate statements of copyright. This is correct. As with many things that are harder for us than for other people, we have =1000 developers and the history thus-far has been for people to be rather antagonistic and annoyed when someone tries to suggest proper copyright attribution. What we CAN say is that every single commit is Apache licensed. Our CLA and enforcement of it, sad as this statement makes me, ensures that we know that. I'm not sure what to do re: FTP masters. Could someone expand for me like I'm an idiot what the goal they are trying to achieve is? I _think_ that they're trying to make sure that the code is free software and that it is annotated somewhere that we know this to be true, yeah? Is there an additional thing being attempted? Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/19/2013 08:22 AM, Monty Taylor wrote: On 10/19/2013 04:52 AM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700: Hi there, TroveClient just got rejected by Debian FTP masters. Reply from Luke Faraone is below. In general, I would strongly advise that a clean COPYRIGHT-HOLDER file is created with the copyright holders in them. Why? Because it is hard to distinguish between authors and copyright holders, which are very distinct things. Listing the authors in debian/copyright doesn't seem to satisfy the FTP masters as well... :( FYI, my reply was that I knew some of the authors were working for Rackspace, because I met them in Portland, and that I knew Rackspace was one of the copyright holders. Though that's of course not enough for the Debian FTP masters. Your thoughts? Recently there was a movement to remove the copyright headers from all the files in OpenStack. Some folk disagreed with this movement, and the compromise was that they were discouraged but allowed. This is not true. The compromise is that they are not required, and that people would stop rejecting patches if they did not include a license header. Correction Would not be rejected if they did not include a *copyright* header. License headers are still required (we even added a hacking rule for that). At no point in time, to my knowledge, did we EVER reach an agreement that they are actually discouraged. We merely acknowledged that we have developer apathy on this point and weren't going to get it right. I think the lack of a firm stance here honestly caused more confusion. I've seen wildly different interpretations on projects because we're in a giant grey area (as can be seen by the different interpretations on this list). Perhaps it's time to open up that giant can of worms again and try to get more specific on copyright requirements though I'm not sure the discussion would end up any differently. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/19/2013 08:29 AM, Sean Dague wrote: On 10/19/2013 08:22 AM, Monty Taylor wrote: On 10/19/2013 04:52 AM, Clint Byrum wrote: Excerpts from Thomas Goirand's message of 2013-10-18 23:01:50 -0700: Hi there, TroveClient just got rejected by Debian FTP masters. Reply from Luke Faraone is below. In general, I would strongly advise that a clean COPYRIGHT-HOLDER file is created with the copyright holders in them. Why? Because it is hard to distinguish between authors and copyright holders, which are very distinct things. Listing the authors in debian/copyright doesn't seem to satisfy the FTP masters as well... :( FYI, my reply was that I knew some of the authors were working for Rackspace, because I met them in Portland, and that I knew Rackspace was one of the copyright holders. Though that's of course not enough for the Debian FTP masters. Your thoughts? Recently there was a movement to remove the copyright headers from all the files in OpenStack. Some folk disagreed with this movement, and the compromise was that they were discouraged but allowed. This is not true. The compromise is that they are not required, and that people would stop rejecting patches if they did not include a license header. Correction Would not be rejected if they did not include a *copyright* header. License headers are still required (we even added a hacking rule for that). At no point in time, to my knowledge, did we EVER reach an agreement that they are actually discouraged. We merely acknowledged that we have developer apathy on this point and weren't going to get it right. I think the lack of a firm stance here honestly caused more confusion. I've seen wildly different interpretations on projects because we're in a giant grey area (as can be seen by the different interpretations on this list). Perhaps it's time to open up that giant can of worms again and try to get more specific on copyright requirements though I'm not sure the discussion would end up any differently. I think it might be time to open it up again - and seems like a good test of our new TC's ability to have a discussion on a potentially hairy topic. The fact that it might be causing a demonstrable issue with the distros might be a good data point that did not exist last time. However, even as a strong supporter of accurate license headers, I would like to know more about the FTP masters issue. I dialog with them, as folks who deal with this issue and its repercutions WAY more than any of us might be really nice. Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] fuzzy testing of client functions
Hello folks, I remember that we had a quick chat about fuzzy testing in a QA meeting. IMHO we have much too many negative tests in tempest that aren't really complex. So I tried to build up a little tool that discovers the parameters of a client functions and randomizes the input for it. It works like this: ./run_fuzzy_test.py image_client update_image -n 100 2013-10-19 13:42:10.634 27748 ERROR ClientFuzzTest [-] Bad request 2013-10-19 13:42:10.658 27748 ERROR ClientFuzzTest [-] Bad request 2013-10-19 13:42:10.670 27748 ERROR ClientFuzzTest [-] must be string or buffer, not int 2013-10-19 13:42:10.709 27748 ERROR ClientFuzzTest [-] Object not found 2013-10-19 13:42:10.738 27748 ERROR ClientFuzzTest [-] Bad request Could you give me some feedback about your thoughts: https://review.openstack.org/#/c/52768 It's maybe just a starting point for a discussion on the summit. Regards, Marc DEUTSCHE TELEKOM AG Digital Business Unit, Cloud Services (PI) Marc Koderer Cloud Technology Software Developer T-Online-Allee 1, 64211 Darmstadt www.telekom.com LIFE IS FOR SHARING. DEUTSCHE TELEKOM AG Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman) Board of Management: René Obermann (Chairman), Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges, Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick Commercial register: Amtsgericht Bonn HRB 6794 Registered office: Bonn BIG CHANGES START SMALL – CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 10/19/2013 08:24 PM, Monty Taylor wrote: On 10/19/2013 05:49 AM, Michael Still wrote: On Sat, Oct 19, 2013 at 7:52 PM, Clint Byrum cl...@fewbar.com wrote: I suggest that we just put Copyright headers back in the source files. That will make Debian's licensecheck work fairly automatically. A single file that tries to do exactly what debian/copyright would do seems a bit odd. The problem here is that the copyright headers were wrong. They aren't religiously added to, and sometimes people have tried to gift code to the Foundation by saying the code is copyright the Foundation, which isn't always true. So, we can't lean on these headers for accurate statements of copyright. This is correct. As with many things that are harder for us than for other people, we have =1000 developers and the history thus-far has been for people to be rather antagonistic and annoyed when someone tries to suggest proper copyright attribution. Though the Debian FTP masters seems to insist on having correct copyright holders in debian/copyright, and I am a bit lost after the 2 rejects I just had. What we CAN say is that every single commit is Apache licensed. Our CLA and enforcement of it, sad as this statement makes me, ensures that we know that. The licensing has nothing to do with copyright holders. These are 2 different topics, please don't mix them in. :) I'm not sure what to do re: FTP masters. Could someone expand for me like I'm an idiot what the goal they are trying to achieve is? I _think_ that they're trying to make sure that the code is free software and that it is annotated somewhere that we know this to be true, yeah? Is there an additional thing being attempted? Monty I believe you are right. I'll point them to this thread. Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Call for a clear COPYRIGHT-HOLDERS file in all OpenStack projects (and [trove] python-troveclient_0.1.4-1_amd64.changes REJECTED)
On 2013-10-19 23:29:28 +0800 (+0800), Thomas Goirand wrote: Though the Debian FTP masters seems to insist on having correct copyright holders in debian/copyright, and I am a bit lost after the 2 rejects I just had. Well, this is still a fuzzy topic. We have a lot of contributions and know who the authors are, but not necessarily who the copyright holders were on behalf of whom they might have contributed various changes (only that the copyright holders authorized them to contribute this work under a specific license, because the authors signed agreements to this effect). It would almost certainly take a policy decision by the technical committee if we wanted to start requiring all authors of new changes to add/update copyright statements accurately on every file they touch, and there is quite probably no chance at all we can precisely nail down historical copyright holder data for previous changes already merged. The licensing has nothing to do with copyright holders. These are 2 different topics, please don't mix them in. :) [...] OH! But you couldn't be more wrong. Licensing has everything to do with copyright holders in this case, because what we're applying is a *copyright license*. ;) -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Does openstack have a notification system that will let us know when a server changes state ?
Like Gabriel said, take a look at Ceilometer for hints, unfortunately there isn't much documentation on how to do it properly (well, you could just stick with kombu as was proposed at https://ask.openstack.org/en/question/2224/novaquantum-notifications-in-rabbitmq/) But please note that, you'd need to set up a separate notification topic, as the default ones are consumed by Ceilometer. More support from oslo documentation would be great, especially about the Service classes, as every project uses them a bit differently - I spent way to long on trying to work it out and ended up borrowing some code from ceilometer's collector. Regards, -- Łukasz [DeeJay1] Jernaś On Fri, Oct 18, 2013 at 11:01 PM, Gabriel Hurley gabriel.hur...@nebula.com wrote: The answer is “sort of”. Most projects (including Nova) publish to an RPC “notifications” channel (e.g. in rabbitMQ or whichever you use in your deployment). This is how Ceilometer gets some of its data. There is common code for connecting to the notification queue in Oslo (the “rpc” and “notifier” modules, particularly), but the exercise of actually setting up your consumer is left up to you, and there are various gotchas that aren’t well-documented. Ceilometer’s code is a reasonable starting point for building your own. As this is an area I’ve been experimenting with lately I’ll say that once you get it all working it is certainly functional and will deliver exactly what you’re asking for, but it can be a fair bit of engineering effort if you’re not familiar with how these things work already. This is an area I hope can be improved in OpenStack in future releases. Hope that helps, - Gabriel From: openstack learner [mailto:openstacklea...@gmail.com] Sent: Friday, October 18, 2013 11:57 AM To: openst...@lists.openstack.org; openstack-dev@lists.openstack.org Subject: [openstack-dev] Does openstack have a notification system that will let us know when a server changes state ? Hi all, I am using the openstack python api. After I boot an instance, I will keep polling the instance status to check if its status changes from BUILD to ACTIVE. My question is: does openstack have a notification system that will let us know when a vm changes state (e.g. goes into ACTIVE state)? then we won't have to keep on polling it when we need to know the change of the machine state. Thanks xin ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] HOT Software configuration proposal
(I really do not understand how the archive is ordered. In the by-thread view, in which all messages with this subject are equally indented, the last message listed is not the chronologically last.) I see that components have parameters. In some uses (invocations) of components, parameters are given actual values. I find it surprising that in the component definitions there are no declarations of parameters. Wouldn't that be helpful or needed? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats!
Kudos to Sreeram. Great work here. From: Sreeram Yerrapragada syerraprag...@vmware.commailto:syerraprag...@vmware.com Reply-To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Saturday, October 19, 2013 1:29 AM To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats! We had some infrastructure issues in the morning and went back to silent mode. I just re-triggered tempest run for your patchset. Also note that until we stabilize our CI infrastructure you would only be seeing postings from vmware minesweeper for passed builds. For failed build we will manually update it on the review. Thanks Sreeram From: Yaguang Tang yaguang.t...@canonical.commailto:yaguang.t...@canonical.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Sent: Friday, October 18, 2013 8:59:19 AM Subject: Re: [openstack-dev] [Nova] VMWare Mine Sweeper, Congrats! How can I enable or trigger Mine Sweeper for VMware related patches? I have update a patch about VMware driver today https://review.openstack.org/#/c/51793/ . but haven't seen any posting results . 2013/10/18 Sean Dague s...@dague.netmailto:s...@dague.net On 10/17/2013 02:29 PM, Dan Smith wrote: This system is running tempest against a VMWare deployment and posting the results publicly. This is really great progress. It will go a long way in helping reviewers be more confident in changes to this driver. This is huge progress, congrats and thanks to the VMware team for making this happen! There is really no substitute for the value this will provide for overall quality. Agreed. Nice job guys! It's super cool to now see SmokeStack and Mine Sweeper posting back on patches. Tip of the hat to the VMWare team for pulling this together so quickly. -Sean -- Sean Dague http://dague.net ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Tang Yaguang Canonical Ltd. | www.ubuntu.comhttp://www.ubuntu.com/ | www.canonical.comhttp://www.canonical.com/ Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Debian Jessie freeze date announced: 5th of November 2014
Hello Thomas, I am sorry to send a reply a little late on this. I plan on working with Debian for my Openstack setups (now I'm on a rhel based setup) and I would really like the latest OpenStack release available. I was initially planning to setup my own mirrors since I always seem to need features from the next OpenStack release. For example Grizzly for me looks too old and some features that were supposed to land on Havana are now scheduled for Icehouse. Given this, I would pretty much like to have J in Debian Jessie. I'm not sure how to approach this or if it's worth the effort on your part given the latest issues you submitted for Havana and since most likely some features in K will probably make me switch to separate mirrors anyway. However, taking into account the rapid development of OpenStack my guess is that the J release should land in Jessie if possible. I will also try to find some time and help out as much as I can with this. Let me know what you decide , probably after the summit. On Mon, Oct 14, 2013 at 7:34 AM, Thomas Goirand z...@debian.org wrote: Hi, The Debian release team has announced the release date for Jessie: https://lists.debian.org/debian-devel-announce/2013/10/msg4.html This means that for this release, we will *not* have any kind of sync with Ubuntu LTS (last time for Wheezy, we froze a few months after the 2012.04 LTS). I haven't made up my mind yet if we should release Debian Jessie with OpenStack Icehouse (to have the same release as the Ubuntu LTS), or with the J release. I'd be happy to gather comments and suggestions about it, and discuss about it at the HK summit. Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Regards, Cristian Tomoiaga ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Gerrit tools
I created some gerrit tools that I think others might find useful. https://github.com/harlowja/gerrit_view The neat one there is a curses based real time gerrit review receiver that uses a similar mechanism as the gerrit irc bot to sit on the gerrit event queue and receive events. So no longer will u web browser haters (and console lovers) have to refresh to see changes. Haha. Hopefully it works for u guys :) Pull requests welcome too :) Sent from my really tiny device... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
